Tag: linux

Opublikowane w

UnARMed.

Na procesorach ARM powstaje sporo sprzętu. Teoretycznie świetnego, bo i niski pobór mocy, i spore możliwości, i niewielka cena.

Przykłady sprzętu opartego o ARM:

  • Toshiba AC100 – smartbook od Toshiby oparty na chipsecie Nvidii Tegra2. Dwurdzeniowy procesor taktowany 1GHz, 512 MB RAM. 8-10h na baterii, możliwość odtwarzania filmów full HD (1080p). Ekran 10,1″. Do tego dysk SSD. Cena? W zależności od wariantu już od 800 zł (polski sklep internetowy).
  • Trim-Slice – Ten sam procesor i chipset, pobór prądu 2-6W wg producenta. 1GB RAM, gigabitowa karta sieciowa. Wersja bez SSD – 199 USD. Oczywiście też umie full HD, więc aż się prosi o dołożenie dysku i przerobienie na domowe media center (plus ew. router, NAS, a dla geeków serwer WWW i shell), albo nawet i desktop.
  • Seagate Freeagent Dockstar – opiszę, bo i mój pierwszy kontakt z ARM, i stosunkowo ciekawy. Tania (pierwotnie ~25 euro; potem podrożały, ale wydaje mi się, że w Polsce nadal do kupienia w okolicach ~45 euro) zabawka pierwotnie mająca służyć za NAS z serwerem WWW. Gigabitowa karta sieciowa, procesor 1GHz, 128 MB RAM. Na oko świetny zamiennik dla HP T5520, służącego mi za router, ale domowy serwerek WWW, shell czy – po dołożeniu karty dźwiękowej USB – player muzyki itp. też spokojnie można uruchomić. Minimalnie lepsze parametry, aktualnie podobna cena, mniejszy pobór prądu. Jak w końcu uruchomię, to dam znać jak się spisuje. Nietypowy także dlatego, że na Dockstar działa niemodyfikowany Debian.

Wady:

  • Niewygórowane parametry – nie ma co ukrywać, 512 MB czy nawet 1GB RAM to obecnie trochę mało, zwłaszcza, jeśli mówimy o desktopie (patrz poprzedni wpis o małej ilości RAM na desktopie). Procesor też nadmiarem mocy nie grzeszy. To raczej tani sprzęt, więc na komplet złącz i ich sporą ilość też nie ma co liczyć (np. Toshiba tylko 1 pełnowymiarowe USB, Dockstar brak czegokolwiek poza USB i ethernetem, nawet audio nie ma).
  • Brak możliwości rozbudowy – zarówno procesor, SSD, jak i RAM są niewymienne, wlutowane na płytę – SoC. W połączeniu z punktem pierwszym powoduje, że przy zwiększeniu wymagań czy awarii któregoś podzespołu trzeba się liczyć z wymianą całego sprzętu.
  • Słabe wsparcie Linuksa od strony producentów – ani Toshiba, ani Trim-Slice nie pozwolą na uruchomienie Linuksa tak po prostu. Instalacja zawsze jest większą lub mniejszą rzeźbą (Dockstar ma niezły, choć nieprzyjazny użytkownikowi instalator, na Trim-Slice niby udało uruchomić się Debiana, ale z kernelem z Ubuntu). Toshiba oficjalnie wspiera tylko Androida, niby da się na AC100 zainstalować Ubuntu 10.10 (oczywiście rzeźba), ale nie działa dźwięk.
  • Nie działają niektóre aplikacje – dobra, nie ma co ukrywać, chodzi głównie o Flasha. Niby nic, ale na tę chwilę niestety Flash jest furtką do multimediów i praktycznie niezbędny do przeglądania Internetu. Być może HTML5 coś w tym temacie zmieni, pytanie czy zmieni i, jeśli tak, to kiedy.

Co dalej? Nie ukrywam, że jestem kibicem energooszczędnych i stosunkowo tanich rozwiązań o dużych możliwościach, a taki właśnie jest ARM. Niestety, w tej chwili trudno rozważać ARM jako pełnowymiarową architekturę pod Linuska, dlatego – nie licząc Dockstara – jestem unARMed. Mam nadzieję, że rosnące zainteresowanie nią Ubuntu i Apple odbije się pozytywnie na wsparciu Linuksa.

Opublikowane w

Praca na desktopie z małą ilością RAM po raz pierwszy

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. Polecenie 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)?

Opublikowane w

Polskie radio w konsoli.

Dziś na kanale padło pytanie jak odtwarzać w konsoli radio z http://moje.polskieradio.pl? Na początku sądziłem, że chodzi o Trójkę itp., wtedy format URLa działający zarówno w mplayer jak i w MPD to wspominany we wpisie o MPD:

mms://stream.polskieradio.pl/program3

Okazało się jednak, że chodzi o pozostałe strumienie. I tu nie jest już tak różowo i prosto. Co prawda podczas poszukiwań (w sumie na koniec) ktoś natknął się na skrypt, który umożliwia odtwarzanie tych strumieni w konsoli, ale wędka lepsza od ryby więc:

  • Każda strona zawiera odtwarzacz w JS.
  • W kodzie odtwarzacza jest link do strumienia.
  • Link do odtwarzacza jest stały.
  • Link do strumienia również jest stały.
  • Strumień da się odtwarzać w mplayerze.

Przykładowo:

Minimax ma URL:

 http://moje.polskieradio.pl/station/33/Minimax

Player JS powstaje przez dodanie /_js/player.js, czyi ma URL:

 http://moje.polskieradio.pl/station/33/Minimax/_js/player.js

Strumienie są nazywane wg schematu k.stream, czyli szukamy:

wget -q -O - http://moje.polskieradio.pl/station/33/Minimax/_js/player.js| egrep "file.*k.*stream"

co daje nam wynik  _obj2.addVariable(’file’, 'k34.stream’);

Cały link do strumienia to:

rtmp://stream85.polskieradio.pl/live/k34.stream

Oczywiście nie dam głowy, że stream85 będzie stała i niezmienna, ale to również widać w źródle playera. Jedyną nieoczywistą częścią było dodanie live – wyłuskane z działających stacji (IIRC z Trójki).

Niestety, taką wersję obsłuży mplayer, ale już nie MPD. Jakby ktoś znalazł rozwiązanie jak tworzyć URL zdatny do MPD – proszę o info. Wersja ze skryptu odpada.

Wam życzę dobrego odbioru, a sobie, żeby stacje radiowe przestały utrudniać ludziom życie i dawały przyjazne konsolowym odtwarzaczom linki. Nie zawsze chce się/można włączyć ciężką przeglądarkę, by posłuchać radia. Niezrównanym ideałem jest tu dla mnie Radio Baobab, które nie tylko daje przyjazny konsoli format, ale również w wolnym formacie ogg (obok innych formatów) i w takiej formie, że się ładnie scrobble’uje.

UPDATE: Mpd w wersji 0.16.2 radzi sobie z URLami typu rtmp:// co oczywiście cieszy.