Drażniący dzwięk podczas pracy na baterii w Ubuntu
Linux Ubuntu jest na tą chwilę chyba najlepszą Linuxową dystrybucją na desktopa. Jest ona jednak nadal świeża i zdarza się, że czasami ma pewne problemy z nowszym sprzętem.
Jednym z takich problemów z którym się zetknąłem jest drażniący pisk czyli dźwięk o wysokiej częstotliwości (ang. high-pitch noise) podczas pracy notebooka na zasilaniu bateryjnym. Przyczyną tego dzwięku jest wyższy tryb ACPI odpowiedzialny z zarządzaniem zasilaniem i temperaturą. Więcej szczegółów technicznych można znaleźć na stronach Intela opisujących C-State Architecture.
Mój notebook ma procesor Intel Centrino (Core2) Duo T5600 i niestety ten problem go dotyczy.
Stare rozwiązanie stosowane w Ubuntu 8.04
W jądrze systemu ustawiona jest możliwość zmiany tego parametru podczas pracy systemu (parametr CONFIG_ACPI_PROCESSOR=y).
Aby dźwięk ustał należy uruchomić komendę:
echo 2 >/sys/module/processor/parameters/max_cstate
Można pokusić się o dodanie takiego skryptu do /etc/acpi.d który ten problem rozwiąże, ale lepiej zastosować następne rozwiązanie.
Szczegółowe informacje można znaleźć tutaj.
Nowe rozwiązanie dla Ubuntu 8.04, 8.10 i 9.04 oraz prawdopodobnie pozostałych
W konfiguracji grub’a, do parametrów kernela należy dodać processor.max_cstate=2, przykładowy wpis:
title Ubuntu 9.04, kernel 2.6.28-15-generic root (hd0,1) kernel /vmlinuz-2.6.28-15-generic root=/dev/mapper/sys-root ro quiet splash processor.max_cstate=2 initrd /initrd.img-2.6.28-15-generic quiet
Rozwiązanie to ma tą wadę – trzeba o nim pamiętać i uzupełniać w konfiguracji gruba nowe kernele o ten parametr. Jeśli to rozwiązanie jest dla Ciebie przydatne to zachęcam do oznaczenia go sobie w Google Readerze jako ulubione, bo kto wie, być może będzie potrzeba aby do niego wrócić 
Mercurial w Eclipse IDE
Środowisko programistyczne Eclipse jest jednym z najlepszych spośród tych dostępnych za darmo. Osobiście preferuję vim’a, ale większość programistów przywykło do większych luksusów
Eclipse jest dostępny zarówno pod Windows jak i pod Linuxem. Jego instalacja w systemie Microsoftu jest dość prostą czynnością.
W Linux Ubuntu, Eclipse jest niby też dostępny w standardowej dystrybucji, ale mnie osobiście nigdy nie udało się go z sukcesem uruchomić ze standardowej paczki. Tym z Was, którzy chcą z niego skorzystać pod Ubuntu zachęcam do pobrania Eclipse z ich strony, następnie rozpakowanie go do docelowego katalogu, a na koniec ręczne stworzenie skrótu.
Eclipse zostało stworzone w Javie i w zamyśle jest IDE służącym do tworzenia aplikacji właśnie w tym języku. Dzięki zaawansowanemu systemowi rozszerzeń możliwe jest jednak jego wykorzystanie do tworzenia aplikacji w innych językach. Właśnie ten mechanizm umożliwi nam również uzupełnienie Eclipse’a o system kontroli wersji.
Aby mieć możliwość z korzystania z Mercuriala, konieczna będzie jego instalacja w systemie. Dla systemu Microsoft Windows można go pobrać z tej strony. Dodatkowo warto zainstalować TortoiseHG. Kroki opisujące instalację pod Linux Ubuntu wraz z TortoiseHG opisałem tutaj.
Wtyczka Mercurial-Eclipse
Aby za pomocą środowiska Eclipse posługiwać się systemem kontroli wersji Mercurial, konieczne będzie dodanie jego repozytorium do dostępnych źródeł w Eclipse. W tym celu wybieramy Help / Install new software… / Add… i podajemy:
name: Mercurial Eclipse
location: http://www.vectrace.com/eclipse-update/
Osobiście testowałem plugina w wersji 1.4.1286 – zainstalował się i działał prawidłowo.
Po zainstalowaniu, plugin poprosi o restart środowiska Eclipse. Kiedy już Eclipse zacznie ponownie działać, powinniśmy mieć dostęp do nowej funkcjonalności.
Dość ważną kwestią jest na początku zaglądnięcie do ustawień Mercuriala – Window / Preferences, wybieramy Team / Mercurial. Należy tutaj podać Mercurial Username w postaci Imię nazwisko <adres@email>. Zaleciłbym również zaznaczenie opcji Automatically associate Mercurial with new projects containing hg repository.
Jeśli chodzi o zakładanie repozytorium dla istniejącego już projektu – w Eksploratorze workspace wybieramy projekt, naciskamy prawy klawisz myszy, następnie Team / Share project – tam wybieramy Mercurial i na następnej stronie wizarda Use project root.
Jeśli repozytorium już było założone – trzeba zaglądnąć do projektu podobnie jak przy tworzeniu nowego repozytorium, wybrać Share project, a na końcu Use existing .hg repository.
W tym momencie możemy już korzystać z bardziej urozmaiconej zawartości popup menu Team
Instalacja Mercurial z GUI TortoiseHG pod Ubuntu 9.04
Mercurial jest jednym z najpopularniejszych ostatnio systemów kontroli wersji. Został on napisany w języku Python i coraz więcej projektów jest do niego migrowanych. Google Code umożliwia wybór jednego z dwóch systemów kontroli wersji – jednym z nich jest SVN, drugim właśnie Mercurial.
Różnice między scentralizowanym a rozproszonym systemem kontroli wersji
Zasada działania Mercuriala jest zbliżona do Git‘a – oba są tzw. rozproszonymi systemami kontroli wersji. SVN z drugiej strony jest systemem zcentralizowanym. Praca na systemie rozproszonym jest o tyle wygodna, że każda lokalna kopia repozytorium może być traktowana jako pełnoprawna i całkowicie niezależna. Rozwijając kod który jest obsługiwany w takim systemie kontroli wersji, commitowanie, czyli zatwierdzanie mniejszych porcji zmian jest znacznie wygodniejsze i nie wymaga zaprzątania głowy głównego repozytorium… którego tak naprawdę wcale nie musi być.
Jak to robi Linus Torvalds?
Większe projekty, takie jak jądro Linuxa coraz częściej przechodzą na rozproszone systemy kontroli wersji. Linus Torvalds bardzo zachęca wszystkich do migrowania do Gita z SVN’a. Git został napisany właśnie z myślą o developerach jądra systemu Linux. Głównymi zaletami według niego są dwie kwestie – pierwsza: znacznie wygodniejsze merge’owanie (łączenie zmian wprowadzonych przez różnych developerów) oraz druga – rozproszone repozytoria pozwalają na hierarchiczne scalanie kodu (z punktu widzenia pracy grupowej). Dzięki tej drugiej, Linus może powierzyć np. opiekę nad modułami jądra dotyczącymi sieci komuś, kto zna się na tym konkretnym temacie lepiej, potrafi weryfikować zmiany i poprawki. Zebrane do repozytorium przez opiekuna drzewa sieci poprawki, Linus może włączyć do jego repozytorium, które traktowane jest jako główne mając pewność, że wszystkie zmiany zostały odpowiednio zweryfikowane.
Kontrola wersji z linii komend
Mercuriala można zainstalować ze standardowego pakietu w Ubuntu. Na pakiet składa się jedna aplikacja – hg. Za jej pomocą można wykonać wszystkie operacje na repozytorium z poziomu linii komend.
$ hg Mercurial Distributed SCM basic commands: add add the specified files on the next commit annotate show changeset information by line for each file clone make a copy of an existing repository commit commit the specified files or all outstanding changes diff diff repository (or selected files) export dump the header and diffs for one or more changesets forget forget the specified files on the next commit init create a new repository in the given directory log show revision history of entire repository or files merge merge working directory with another revision parents show the parents of the working directory or revision pull pull changes from the specified source push push changes to the specified destination remove remove the specified files on the next commit serve export the repository via HTTP status show changed files in the working directory update update working directory view start interactive history viewer use "hg help" for the full list of commands or "hg -v" for details
Kontrola wersji z poziomu interfejsu graficznego
Istnieje jednak możliwość pracy graficznej. Windowsowi użytkownicy jako graficzny interfejs zwykle wykorzystują TortoiseHG, który wywodzi się z TortoiseSVN. Pod Linuxem możemy również wykorzystać TortoiseHG.
Instalacja Mercuriala i TortoiseHG pod Ubuntu 9.04
Uruchomienie komend zamieszczonych poniżej sprawi, że nasz Mercurial zostanie „podniesiony” do najnowszej stabilnej wersji, pojawi się nam TortoiseHG również w wersji stabilnej, a następnie TortoiseHG zostanie włączone do domyślnego menadżera plików w Gnome – Nautilusa. Zainstalowana zostanie również aplikacja Meld, która czyni merge’owanie całkiem przyjemną czynnością w interfejsie graficznym
# Najpierw przechodzimy na roota, tego którego w Ubuntu nie masudo -i # Dodajemy drzewo stable repozytorium Mercuriala z Ubuntu Launchpad PPA cat >/etc/apt/sources.list.d/mercurial.list << EOF deb http://ppa.launchpad.net/mercurial-ppa/stable-snapshots/ubuntu jaunty main deb-src http://ppa.launchpad.net/mercurial-ppa/stable-snapshots/ubuntu jaunty main EOF sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key 323293EE # Dodajemy drzewo stable repozytorium TortoiseHG z Ubuntu Launchpad PPA cat >/etc/apt/sources.list.d/tortoisehg.list << EOF deb http://ppa.launchpad.net/tortoisehg-ppa/stable-snapshots/ubuntu jaunty main deb-src http://ppa.launchpad.net/tortoisehg-ppa/stable-snapshots/ubuntu jaunty main EOF sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-key D5056DDE # odświeżamy listę repozytoriów i pobieramy pakiety oraz dodajemy obsługę bindingsów Pythona w Nautilusie aptitude update aptitude install -y python-nautilus mercurial tortoisehg tortoisehg-nautilus meld # doinstalowujemy pakiet iniparse wget http://iniparse.googlecode.com/files/python-iniparse_0.3.1-1_all.deb dpkg -i python-iniparse_0.3.1-1_all.deb rm python-iniparse_0.3.1-1_all.deb
Po wykonaniu tych komend najlepiej się przelogować ponownie, aby Nautilus zdał sobię sprawę z wprowadzonych zmian. Można też (już na swoim użytkowniku) uruchomić komendę:
nautilus -q
Która spowoduje przeładowanie Nautilusa (może nam zniknąć do następnego zalogowania zawartość pulpitu). Jeśli wszystko pójdzie pomyślnie, w efekcie możemy zarządzać repozytorium w następujący sposób:
Powiadomienie SMS na OVH
Ten wpis jest zwieńczeniem trzech poprzednich i opisuje w jaki sposób umieścić skrypty na koncie shellowym. Jako, że już wspomniałem, że na chwilę obecną korzystam z usług OVH, uważam, że warto opisać, jak takie powiadomienia u nich uruchomić.
Potrzebne są dane do konta w Gmailu z aktywowanym kalendarzem. Jeśli chodzi o pliki – wystarczy biblioteka kliencka Google oraz przygotowana przeze mnie paczka. Oba pliki umieszczamy na koncie w katalogu domowym, logujemy się za pomocą ssh, po czym wydajemy następujące komendy:
tar jxvf sms-notify.tar.bz2 mkdir -p lib/api cd lib/api tar zxvf ~/gdata-2.0.1.tar.gz cd .. ln -s api/gdata-2.0.1/src/atom ln -s api/gdata-2.0.1/src/gdata cd ~
następnie edytujemy plik z ustawieniami ustawiając konto i hasło dla aplikacji:
nano lib/conf.py
Kiedy już to zrobimy – możemy sprawdzić czy działa pojedyncze powiadomienie:
./lib/sms.py @ovh testowe powiadomienie
SMS powinien przyjść na komórkę po czasie 1 minuty. Jeśli wszystko pójdzie dobrze, możemy wysłać na to konto pocztowe maila, a następnie wymusić pojedyncze sprawdzenie:
./lib/pop2sms.py
Następnie możemy sprawdzić te same operacje z poziomu skryptów CGI; w celu wysłania SMSa – odwiedzamy:
http://www.twoja-domena.pl/cgi-bin/sms.py?q=@gdzieś treść powiadomienia
a kiedy wyślemy sobie na konto maila, możemy sprawdzić czy doszedł, a następnie przekierować do komórki odwiedzając:
http://www.twoja-domena.pl/cgi-bin/pop.py
Jeśli wszystko działa, pozostaje nam tylko zalogowanie do interfejsu zarządzającego OVH i ustawienie crona… Niestety jednak, na ich serwerach sytuacja jest dość nietypowa, ponieważ najczęstszym wywołaniem nie jest wywołanie co minutę, ale co godzinę. Obniża to niestety odrobinę responsywność naszego automatu. W niektórych sytuacjach może to być akurat plus, ale jakby na to nie patrzeć – niestety – wymuszony ograniczeniami… Jeśli ktoś potrzebuje częstszych powiadomień – musi niestety umieścić skrypty w miarę możliwości na innych serwerach (lub ustawić / poprosić kogoś, kto ma konto gdzieś indziej, aby uruchomił u siebie skrypt wykonujący HTTP GET do naszego skryptu pop.py).
Decydując się na wykorzystanie OVH, warto pomyśleć o zmianie nazw plików w katalogu cgi-bin na bardziej losowe, np. sms.py -> sms-d9pVExhQg.py – dzięki temu zabiegowi możemy uniknąć ślepych prób uruchamiania skryptów z katalogu cgi-bin. Dla własnego użytku można dodatkowo ustawić sobie odpowiedni wpis w .htaccess za pomocą mod_rewrite, który będzie łatwiejszy do zapamiętania i wygodniejszy w użyciu.
Przedłuż czas życia dysku twardego
Dyski SSD (Solid State Drive) są w momencie pisania tego tekstu wciąż drogie, a ich pojemności są nieporównywalnie mniejsze od dysków starego typu. Warto zatem zadbać jeszcze przez kilka lat o swoje stare dyski, aby mogły nam służyć przynajmniej do momentu, kiedy te dwa parametry zaczną się między nimi zacierać
Jeśli używamy w laptopie dysku twardego starego typu (mechaniczne, z talerzami) powinniśmy zdawać sobie sprawę z faktu, że na jego czas życia wpływa wiele parametrów. Jedym z nich jest ilość cyklów parkowania/odparkowania (ang. load/unload cycles), który dla większości dysków przewidziany jest przez producenta na około 600 000. Liczba ta jest wysoka, ale można ją niechcący bardzo szybko przekroczyć. Okazuje się, że może się tak zdarzyć, że nasz świeżo zainstalowany system, wraz ze sterownikami i oprogramowaniem do oszczędzania energii sprawi, że dysk będzie parkowany co minutę.
Wszystkiemu winne oszczędzanie energii w wydaniu producentów dysków twardych. Kto wie, może jest to wybieg celowy. System operacyjny, bez znaczenia czy jest to Windows, Linux czy coś innego, ustawia sprzętowi tryb pracy APM (Advanced Power Managment). Jeśli dysk twardy obsługuje APM, przechodzi w odpowiedni tryb pracy. Czym tryb będzie bardziej energooszczędny – tym dysk będzie starał się parkować głowice po krótszym czasie bezczynności.
Parametr trybu APM może przyjąć wartość w zakresie 0-255. Domyślna wartość dla pracy bez zasilania to 128, a dla pracy z zasilaniem – 254 (chociaż bezpieczniej jest wyłączyć APM ustawiając ten parametr na 255). Problem w tym, że systemy operacyjne bądź z powodu ustawień domyślnych (np. Ubuntu Linux), bądź z powodu sterowników dołączonych do notebooka (np. sterowniki Fujitsu Lifebook S dla Windows XP) ustawiają te parametry niewłaściwie.
Rozwiązanie problemu dla Windows
Trzeba wykorzystanie aplikację QuietHDD. Program należy wypakować do lokalizacji docelowej, a następnie utworzyć do niej skrót. Po uruchomieniu programu, w jego lokalizacji tworzy się plik ini z utawieniami. Możemy wtedy ustawić tryb APM na 255, a następnie zamykamy program. Przygotowany wcześniej skrót można zaopatrzyć w dopisek /notray, a następnie trzeba go przenieść do Autostartu.
Rozwiązanie dla Linux Ubuntu
Źródło, tłumaczenie:
- stwórz plik o nazwie
99-hdd-spin-fix.sh. Ważne jest, aby zaczynał się od99. - uzupełnij plik o następujące 2 linie:
#!/bin/sh
hdparm -B 255 /dev/sda - skopiuj plik do 3 lokalizacji:
/etc/acpi/suspend.d/
/etc/acpi/resume.d/
/etc/acpi/start.d/
Panowie z Ubuntu obiecują, że naprawią problem w nowej wersji systemu, ale od tamtego czasu numerki wersji już kilka razy się zmieniły. Powyższe rozwiązanie do najładniejszych nie należy, ale się sprawdza.
Dodatkowo, sprawdzenie stanu APM wykonujemy komendą:
sudo hdparm -I /dev/sda | grep level
Sprawdzenie obecnej ilości cyklów możemy sprawdzić wydając:
sudo smartctl -a /dev/sda | grep Load
Jako, że era tego rodzaju dysków dobiega powoli końca, warto zobaczyć jak wyglądał jeden z pierwszych modeli
