Pomiędzy bitami

O Rockbox 3.11 nie napisałem nic, bo wcześniej napisali inni w polskiej sieci, a i dopiero niedawno go wgrałem na moje urządzenie, bo wielkich zmian (dla mnie) nie było, więc donoszę o wersji 3.11.2, która zawiera wyłącznie poprawki błędów, w tym naprawia radio dla Sansa e200 i c200. Czyli dla mojego playera. Nie żebym z radia korzystał... ;-) Tradycyjnie pełna lista zmian dla Rockbox 3.11.2.

Jeśli ktoś posiada Debiana w wersji 32bit (architektura i386) i korzysta z niewolnego pluginu flash (pakiet flashplugin-nonfree), to niech uważa z aktualizacją flasha do wersji 11.2.202.228. Wygląda, ze jest bug i po aktualizacji do ww. wersji flash przestaje działać i to we wszystkich przeglądarkach (sprawdzone w Iceweasel, Opera, Chromium). Problem objawia się tak, że sam plugin jest widoczny w przeglądarce, ale po prostu obiekty flash nie są uruchamiane.

Sprawdzone na 2 niezależnych systemach, z czego jeden to praktycznie czysty Squeeze, a drugi "mieszaniec" (Squeeze + backports + unstable). Pierwotnie podejrzewałem kombinację Iceweasel 11 + upgrade flash, ale nie o to chodzi. No i z kanału #debian wiem, że nie jestem jedyną ofiarą błędu.

PS Dla architektury amd64 błąd nie występuje - wszystko działa poprawnie, można spokojnie aktualizować. Jak będę znał rozwiązanie, to pojawi się aktualizacja.

UPDATE: Z tego co widzę w sieci, problem dotyczy wszystkich dystrybucji Linuksa i tylko architektury i386: https://bugbase.adobe.com/index.cfm?event=bug&id=3154276 https://bugbase.adobe.com/index.cfm?event=bug&id=3161034 http://forums.gentoo.org/viewtopic-t-918560-postdays-0-postorder-asc-start-0.html Adobe nie spieszy się do naprawy, jako, że plugin dla Linuksa oficjalnie nie jest wspierany. W którymś wątku pojawiła się sugestia, że wyłączenie akceleracji video rozwiązuje problem (nie weryfikowałem).

UPDATE: Widzę w pytaniach do wyszukiwarki pytanie o alternatywy dla flash, więc dla porządku: jest GNU Gnash, który działa średnio, że tak to ujmę (mało wydajny przede wszystkim z tych paru chwil, kiedy korzystałem) i jest Lightspark, z którym zupełnie nie miałem styczności, a który może być bardziej wydajny, bo przepisany od zera z myślą o wydajności na współczesnym sprzęcie.

Jakiś czas temu pisałem o pierwszym podejściu do małej ilości RAM na desktopie, więc pora na część drugą. Przejrzałem podrzucone linki nt. optymalizacji działania dekstopu. Dysk był już ustawiony optymalnie, niepotrzebne usługi powyłączane, więc tak naprawdę tylko zmniejszyłem ilość uruchamianych konsol w inittabie. Nie zauważyłem zmiany w ilości zużywanego RAM, ale i tak ich nie potrzebuję - dwie wystarczają z naddatkiem. Swappiness nadal jest ustawione na 0 i IMO działa OK.

Zauważyłem, że spowalnianie występuje głównie na jednym desktopie (tym w pracy, starszy, bardziej zapchany dysk), przy pracy z pakietami (aktualizacja listy, instalacja), co skłania mnie do wniosku, że głównym winowajcą jest fragmentacja filesystemu. W obu przypadkach jest to ReiserFS (zaszłość, kiedyś był najlepszym wyborem, teraz chętnie widziałbym ext4 w tym miejscu), ale w domu z pewnością fragmentacja jest mniejsza - pół dysku zawsze było wolne.

Tak czy inaczej, wydaje mi się, że wypracowałem sposób na drastyczne ograniczenie spowalniania komputera przy pracy z pakietami. Korzystam z niego mniej więcej raz na tydzień. Cudów nie ma, czyli najpierw zamykam programy, które zużywają najwięcej RAM: Iceweasel, czyli Firefox, Icedove, czyli Thunderbird i PSI. Trwa to chwilę, a zwalnia znaczne obszary RAM.

Następnie uruchamiam prosty skrypt, który robi sync na dyskach, opróżnia bufory dyskowe, a następnie wyłącza i ponownie włącza swap.

#!/bin/bash

echo Syncing hard discs
sync
sleep 5
sync

echo Flushing disc buffers
echo 3 > /proc/sys/vm/drop_caches

echo Turning swap off
swapoff -a

echo Turning swap on
swapon -a

Celem jest najpierw zwolnienie jak największego obszaru pamięci, a następnie wymuszenie przerzucenia danych ze swap do RAM. Szybsze od restartu, działa w tle, więc można pracować w tym czasie. Po wykonaniu skryptu można swobodnie uruchomić przeglądarkę, pocztę, komunikator i aktualizować system. Najgorsze co może się wydarzyć, to niewyłączenie swapa, jeśli nie będzie wystarczającej ilości dostępnej pamięci, ale nie jest to krytyczne i zdarza się rzadko (zwł. po wyłączeniu przeglądarki). Wydaje mi się, że po takim zabiegu system działa znacznie lepiej.

Źródło: karta kredytowa.

Ponieważ mBank wprowadził opłaty za kartę, co wyjątkowo mi się nie spodobało i się najprawdopodobniej niebawem pożegnam przynajmniej z ich kartą, postanowiłem założyć inne konta. Jako pierwsze, zostało wybrane konto dbNET Deutsche Banku - to co w mBanku do tej pory, czyli zero opłat za prowadzenie, przelewy przez Internet oraz kartę debetową pod warunkiem 1 transakcji kartą miesięcznie (w przeciwnym wypadku 5 zł miesięcznie za kartę). Do tego bezpłatne wypłaty z bankomatów na całym świecie i - jeśli komuś zależy - wygląda, że lepsze oprocentowanie.

Ponieważ miałem parę pytań, udałem się do placówki. Pierwsza informacja od pracownika banku - za transakcję uznawana jest także wypłata gotówki w bankomacie. Miłe i czyni pilnowanie transakcji totalnie bezproblemowym - wypłaty z bankomatów to podstawowa funkcja z której korzystam. Oczywiście zobaczymy, jak będzie w praktyce, ale jedne zakupy też mogę kartą zrobić.

Druga informacja, tym razem negatywna - konto trzeba załatwiać przez Internet i kuriera. Bardzo nie na rękę, bo chciałem założyć na miejscu - oddział mam blisko, z adresami lekkie zamieszanie i przeczucie, że z kurierem będą problemy. Dostałem radę, żebym założył na stary adres, jako adres odbioru podał korespondencyjny, a potem zmienił korespondencyjny. Na szczęście nie było to potrzebne - procedura dopuszcza podanie adresu odbioru przesyłki jako niezależnego od adresu stałego zameldowania i adresu korespondencyjnego. Nie rozumiem, czemu nie ma możliwości założenia tego konta w oddziale, bo podczas paru wizyt (kumpel załatwia często sprawy po drodze, więc bywam) liczba pracowników przewyższała tam liczbę klientów...

Trzecia informacja, również negatywna - nic nie wiedzą o wprowadzeniu haseł jednorazowych przesyłanych przez  SMS. A gdzieś na jakimś forum/blogu, szukając informacji o tym koncie wygooglałem, że taka funkcjonalność jest planowana w sierpniu. Zamiast tego jest karta TAN, której idea mi się nie podoba (ale o tym później/innym razem).

Wypełniłem wniosek przez Internet - całkiem przyjemne, jedyna wada to fakt, że przy końcu pyta o potwierdzenie zaznajomienia się z kilkoma dokumentami (PDFy, kilkadziesiąt stron). Przeczytanie tego zajęło dłuższą chwilę, po czym po zatwierdzeniu i wybraniu kontynuacji okazało się, że "uzupełnij dane", a wszystkie wprowadzone do tej pory dane są wyczyszczone. Irytujące, szczególnie, że zakładają, że ludzie i tak nie przeczytali dokumentów - w mailach otrzymanych później znowu zachęcają do przeczytania tychże PDFów, więc wymóg zatwierdzenia taki trochę od czapy.

Nie pomyliłem się co do problemów z kurierem. Przedstawiciel InPost zadzwonił w piątek i umówił się na sobotę, po czym zwyczajnie nie przyszedł, nawet nie racząc odwołać wizyty (a był proszony o telefon przed, żebym - na wypadek gdybym wyszedł, zdążył wrócić). Po paru dniach zadzwoniła pani z InPost, że mają przesyłkę i że... "adresat był nieobecny". Ta jasne. Ostatecznie, zamiast w sobotę, to w środę, udaje się im dostarczyć przesyłkę.

Pora na aktywację. Rzut oka na instrukcję (przejrzysta i dobrze opisana), telefon na podany numer, w sensowny IVR, szybkie połączenie z konsultantką, seria durnych pytań (imię i nazwisko, choć przed chwilą się przedstawiłem), ale taka procedura. Skupić się i nie dywagować (na pytanie czy ma Pan konto w naszym banku odpowiadam twierdząco w ostatniej chwili gryząc się w język i hamując jeszcze nie, właśnie jestem w trakcie zakładania; niech wasza mowa będzie tak, tak, nie, nie). Kod dwa razy. Rozłącz. Poniżej 5 minut. Nieźle, biorąc pod uwagę, że wysłuchiwałem całego IVRa.

Próba zalogowania przez net z użyciem świeżo założonego kodu zakończona porażką: Niepoprawne dane do autoryzacji / Authorization fault, nara. Co ciekawe NIK ma 10 cyfr (ciekawe czy kiedykolwiek nauczę się go na pamięć), kod dostępu 6 - trochę mało, szczególnie, że muszą być cyfry, dokładnie 6 i tylko cyfry. Mało i szkoda, że nie ma liter - te łatwiej zapamiętać. No ale 6 "losowych" cyfr nie jest problemem.

Nie ruszyło aż do następnego dnia. Ponowny telefon (sobota przed 8 rano) i ponowne ustawienie kodu. Łączny czas połączenia - lekko ponad 3 minuty. Tym razem mogę się zalogować. Dziwne, bo kod dokładnie ten sam, wymyślony wcześniej, więc raczej nie zrobiłem błędu. Niestety, po zalogowaniu widzę Internet service is currently unavailable. Wszystko po angielsku, próba przełączenia polski lub niemiecki nie działa. Nieszczęścia chodzą najwidoczniej parami, mBank nigdy, przez parę lat korzystania mi czegoś takiego nie odwalił.

Po paru godzinach próbuję zalogować się ponownie. Tym razem działa. Obejrzałem sobie, nie wygląda źle, zobaczymy jak będzie w praktyce. Niestety, tym razem znowu bug - mało profesjonalnie (eufemizm) wygląda debetowa, ???pl_PL.kartSUOLista.status.P??? jako rodzaj karty.

Pierwsze wrażenie - tylko 3/10. Niezłe przemyślenie i przygotowanie zepsute jest niestety przez wykonanie, a problemy z serwisem przy koncie internetowym przepełniają czarę goryczy. Jak konto mBanku był przez lata jedynym bankiem, tak konto dbNET na pewno nie dostanie takiej szansy po tym wstępnie.

UPDATE: Aktywowałem też kartę i kody TAN (w sumie bez sensu była aktywacja samego konta, tyle że sobie pooglądałem). Nie sprawdzałem jeszcze, czy działa, ale co ciekawe, tym razem zostałem poinformowany, że kod dostępu może "ruszyć" dopiero jutro po 8 rano "bo jest po 18 już i może to nie zadziałać dziś". Co wyjaśnia problemy opisane 3-4 akapity wyżej. Czas aktywacji: 6 minut.

Zniknął też podany dziwny komunikat nt. stanu karty, jest trochę lepsze (ciekawe czy wynikające z aktywacji) debetowa, Production in progress. Tylko trochę, bo i po angielsku, i niezupełnie zgodnie ze stanem faktycznym (no dobra, niech będzie, że "się aktywuje").

Jakby tak było od razu to 5/10. Przydałoby się trochę dopracować procedury...

Tak się złożyło, że w użyciu jest sobie Quagga. Złożyło się też tak, że pobierane z niej są pewne dane przy pomocy polecenia vtysh. W postaci:

vtysh -c "show ip bgp neighbors  advertised-routes"

Następnie wynik polecenia jest parsowany skryptem. Generalnie chodzi o pobranie sieci w notacji CIDR. I wszystko byłoby fajnie, ale Quagga w ramach kompatybilności wstecznej (it's not a bug, it's a feature!) zwraca czasem samo IP. Niejednoznacznie, przez co z prostego w założeniu skryptu powinien zrobić się automat domyślający się, czy chodzi o /8, /16 czy /24.

Szukałem informacji czy można coś z tym zrobić na kanałach IRCowych, dostałem dane, że nie ma opcji, by zmienić takie zachowanie, tzn. aby Quagga zwracała jednoznacznie (np. uruchomienie z jakąś opcją). Za to było zainteresowanie ew. znalezionym rozwiązaniem. Nie znalazłem. Wygląda, że po prostu się nie da (tak, wiem, zawsze można pogrzebać w kodzie...).

Nie znalazłem też prostej koncepcji na określanie, o jaką długość prefiksu chodzi w danym przypadku. Akurat w przypadku, w którym używam średnio mi na tym zależy, ale elegancko byłoby móc jednoznacznie określić o jaki prefiks chodzi. Pomysły mile widziane. Przychodzi mi do głowy sprawdzanie, czy dla /8 i /16 nie ma nakładających się sieci z prefiksami określonymi wprost. Wtedy wiadomo, że chodzi o /24.

PS. Wiem, że jest BIRD. Jest rozważany, ale to trochę inny temat.

Tło problemu.

Tak się składa, że apetyt programów i systemów na pamięć RAM systematycznie rośnie, a moje desktopy ilością RAMu nie grzeszą. Faktem jest, że RAM jest teraz tani i praktycznie nie sposób kupić nowego komputera z mniej niż 2-4 GB RAM (chyba, że netbook jakiś), ale... nie każdy sprzęt jest nowy (mój nie jest), nie każdy pozwala na większą ilość RAM no i - przede wszystkim - inwestowanie w stosunkowo drogi, stary RAM do równie starego sprzętu nie ma IMO sensu. A skoro działa, to po co wymieniać? ;-)

Poza tym, Linux potrafi działać na komputerach z małą ilością RAMu. Przynajmniej powinien umieć. W każdym razie możliwa jest w miarę komfortowa praca na desktopach z 0,5-1 GB RAM, nawet z KDE (3.5), chociaż ostatnio pożegnałem się z KDE i zwykle używam LXDE. Oczywiście zależy, co się robi, ale przy typowym korzystaniu, typu włączenie komputera, uruchomienie paru programów (komunikator, przeglądarka WWW, konsola, coś do PDF, jakiś arkusz kalkulacyjny czy edytor tekstu itp.) i wyłączenie komputera na koniec dnia, wszysko było OK, nawet na 0,5 GB nie odczuwałem specjalnego spowalniania i wykorzystania swap (czasem się zdarzało, ale nie jakoś krytycznie), ale odkąd korzystam z laptopów, hibernacji lub niewyłączania komputera, jest znacznie gorzej.

Główni winowajcy (na laptopie firmowym) to: Firefox 4 - 21% RAM, Icedove - 7,5%, Xorg - 5,4%, plugin-container (czytaj: flash) 3,8%, psi - 3,4% i konsole 2,8%. Na prywatnym lapku podobnie, tylko Firefox 3.6 zajmuje 11%, i dochodzi Chromium 6,7% (najwyższe wystąpienie, jest ich kilka) i liferea 5,4%. Niby nic specjalnego, ale po kilkunastu dniach okazuje się, że na swapie użyte jest 100-400 MB, a przy odpaleniu jakiejś większej aplikacji (czytaj Openoffice) dysk zaczyna ostro pracować. Przy czym dyski w laptopach to zwykle 5400 rpm, więc raczej nie są demonami szybkości... Jednak najgorsze dzieje się przy instalacji aktualizacji - wajig daily upgrade praktycznie zabija maszynę, do tego stopnia, że chwilowo traci responsywność - trzeba czekać na przełączenie się między oknami, kursor myszy nie porusza się płynnie itp.

Podejście pierwsze: zmiana parametru swappiness.

Określa on, jak chętnie system korzysta ze swap na dysku i przyjmuje wartości od 0 do 100 (szerszy opis parametru swappiness i dyskusja). Domyślnie wynosi on 60, co niekoniecznie jest wartością dobrą dla desktopa. Jak widać, trwa spór o to, czy lepiej ustawić 0 czy 100. Wyszedłem z założenia, że 0 jest lepszą wartością.

Tymczasowe ustawienie wartości swappiness na 0:

echo 0 > /proc/sys/vm/swappiness

Sprawdzenie aktualnego ustawienia:

cat /proc/sys/vm/swappiness

Jeśli chcemy, aby zmiana była wykonywana przy każdym uruchomieniu, to do /etc/sysctl.conf dodajemy linię:

vm.swappiness = 0

Dla jasności: ustawienie swappiness na 0 nie powoduje, że system w ogóle nie korzysta ze swap. Korzysta, jeśli musi tylko mniej chętnie w normalnych warunkach. Efekt: większość czasu jest lepiej, widać, że system praktycznie nie korzysta ze swap. Niestety, jak już zacznie korzystać, to utrata responsywności jest większa, niż przy domyślnej wartości 60 (ocena metodą najdoskonalszą, czyli na oko), więc nie do końca o to mi chodziło.

Podejście drugie: dodanie compcache.

Okazało się, że w Debianie w końcu pojawił się compcache w postaci pakietu o nazwie compcache-tools. Pakiet jest nieco śmieszny (tzn. kwalifikuje się to na bug report...), bo działa na kernelu 2.6.32 ze Squeeze, natomiast na 2.6.38 z testing/unstable brakuje modułu, choć sam pakiet właśnie testing/unstable jest. W skrócie - działa to tak, że zamiast po prostu zapisywać dane z RAM na dysk, najpierw dodatkowo je kompresuje (w RAM), a dopiero potem ew. zrzuca na dysk. Czyli większe użycie procesora w zamian za mniejsze zużycie pamięci i mniej operacji na dysku.

Aktywacja compcache (nieco inna, niż w manie, wersja z mana z insmod nie działała):

modprobe ramzswap

rzscontrol /dev/ramzswap0 --memlimit_kb=153600 --backing_swap=/swapfile.swp --init

swapon /dev/ramzswap0

Kolejno: załadownie modułu, określenie parametrów i inicjacja kompresowanego swap (tu: 150 MB RAM i wykorzystanie swap w pliku /swapfile.swp), aktywacja swap. Miałem to włączone przez kilkanaście dni, łącznie ze swappiness 0, ale nie podejmuję się oceny. IMHO niespecjalnie się różni od gołego zmniejszonego swappiness. Natomiast po reboocie system podziałał z 2 dni (bez włączonego compcache) i... system plików (reiserfs) przemontował się w RO. Fsck znalazł błędy, przebudowanie drzewa naprawiło, ale... zgubił 76 plików - i tak były niedostępne (nic krytycznego, głównie moduły Perla).

WTF? Przecież nigdy wcześniej takich cyrków nie było. Co więcej, przy próbie włączenia compcache otrzymałem komunikat typu backing swapfile has holes. To z kolei naprowadziło mnie na ten opis problemu. Niestety, pasuje idealnie, co skutecznie zniechęciło mnie - przynajmniej na jakiś czas - do zabaw z compcache. Odkryłem co prawda nieużywaną partycję swap, której mógłbym użyć, zamiast pliku, ale najpierw doczytam dokładnie. Uszkodzenia systemu plików to nie jest to, co tygrysy lubią najbardziej.

The end?

Zanim będę kontynuował, pozwolę sobie zapytać, jakie ustawienia parametru swappiness i ew. inne ustawienia proponujecie dla desktopa z Linuksem i LXDE, stosunkowo mocnym procesorem i stosunkowo małą ilością pamięci RAM (1 GB)?

Ostatni upgrade systemu (z prywatnych, głównie desktopy) do Squeeze'ego zakończony. Zasadniczo bez zgrzytów, poza tym, że wyglądał trochę inaczej niż inne, a pakietów było mnóstwo. Naprawdę mnóstwo, apt-cacher wiele nie pomógł, choć inny desktop też z niego korzysta. KDE4 robi swoje, niestety. Łącze 1Mbps to przeżytek. No i jeszcze szopka z upgrade do grub2 była.

Desktop ma uszkodzony RAM, więc korzystam ze sposobu na uszkodzoną pamięć RAM, który opisywałem wcześniej. W grub miałem wpis:

/boot/vmlinuz-2.6.32.11 root=/dev/hda2 ro memmap=2M$311M

Przy dist-upgrade wszytko wykrył poprawnie, łącznie z dodatkowymi opcjami. Oczywiście skorzystałem z proponowanej opcji chainload (i całe szczęście...). Po reboocie wchodzę do grub2, tam wybieram nowy kernel (dystrybucyjny) i... reboot. Bez żadnego komunikatu. Niefajnie. Niestety to samo powtórzyło się przy wybraniu z grub2 kernela własnej roboty, którego używałem na Lenny.

Za to - ku mojemu zdziwieniu - ze starego gruba nowy kernel zadziałał. Co ciekawe, w przeciwieństwie do wersji z Lenny'ego, obsługiwał poprawnie wpis dla memmap - przy szybkim teście podlinkowanym wyżej nie było błędów.

Chwila zabawy i jasne było, że coś się skopało. Zamiast memmap=2M$311M było widoczne... memmap=2M11M. WTF? A po usunięciu opcji memmap wszystko ładowało się poprawnie (tyle, że korzystając ze skopanego obszaru RAM). Chwila googlania i wydało się, że do /etc/default/grub trafiła linia

GRUB_CMDLINE_LINUX="memmap=2M$311M"

która po przetworzeniu przez *sh będzie faktycznie wyglądała tak, jak wyglądała, bo $3 zostanie uznane za zmienną... Grub2 dodatkowo wymaga w swoim menu postaci memmap=2M\$311M czyli ostatecznie poprawna wersja w pliku /etc/default/grub to:

GRUB_CMDLINE_LINUX="memmap=2M\\\$311M"

Jutro zgłaszam buga.