Skusiłem się i za namową Citizena, zgłosiłem ten blog do zagranicznej planety Gentoo¹. Zostałem więc dodany i z tego co widzę, na dzień dzisiejszy jestem tam drugim Polakiem

Większość tamtejszych bloggerów pisze po angielsku, ale można dostrzec też kilku trzymających się języki niemieckiego i innych. Więc czemu by nie “zaśmiecić” im planety moimi wpisami

Zapraszam resztę osób prowadzących blogi o tematyce poruszającej dystrybucje Gentoo Linux, do zapisanie się. Potrzebne informacje znajdują się na dole strony planety.

Nie ukrywam, że brakuje mi takiej planety, zrzeszającej nasze Polskie blogi

Sprawa z Chuckiem Norrisem ostatnim czasy troche przycichła. Ale dla prawdziwych fanów i tych lubiących dowcipy o Chucku Norrisie, powstała baza z fortunkami¹. Jeśli ktoś jest zainteresowany, to może w łatwy sposób podpiąć owe fakty do swojego fortune.

# emerge fortune-mod-chucknorris
$ fortune chucknorris
Q: How many Chuck Norris' does it take to change a light bulb?
A: None, Chuck Norris prefers to kill in the dark.

Możemy to wszystko jeszcze oprawić w ładną krowę, stworzoną w ASCII.

# emerge cowsay
$ fortune chucknorris | cowsay

Efekt taki, jak poniżej.

Sunrise¹ to nakładka na drzewo Portage, zawierająca nieoficjalne, nadesłane przez użytkowników ebuildy. Korzystanie z niej jest na pewno bardziej wygodne, niż z Bugzilli. Ponadto ebuildy są ściśle kontrolowane i moderowane.

Najszybciej uzyskamy do niej dostęp poprzez aplikacje layman (gdy mamy ją zainstalowaną i skonfigurowaną) :

# layman -a sunrise

To wszystko … Pakiety z Sunrise są już widoczne w naszym Portage.

Przeglądając zasoby Sunrise natrafiłem na kilka przydatnych pakietów, które po krótce opisze :

• xorg-edit dla osób lubiący wszechobecne GUI. Xorg-Edit to graficzna nakładka w dużym stopniu pomagająca niektórym osobom zmianę konfiguracji X’ów, czyli pliku xorg.conf.

• qtcurve to styl dla KDE, którego sam obecnie używam. Zawiera kilka wariantów konfiguracyjnych i prezentuje się bardzo ładnie.

• polyester to kolejny styl dla KDE.

• feed2imap to czytnik RSS, który pobrane nagłówki przenosi (w formie maili) na serwer IMAP. Dzięki temu możemy użyć np. Evolution czy innego klienta poczty (nawet Mutt), do czytania zarówno poczty jak i kanałów RSS.
• pcmanfm - szybki i elastyczny menedżer plików, lecz w mniejszym stopniu konfigurowalny od Rox’a. Spełnia swoje zadanie i na pewno wielu osobom przypadnie do gustu.

Dzisiaj zauważyłem, że moja partycja o pojemności 7GB, przeznaczona na Gentoo jest w całości zapełniona. Jak zwykle w takiej sytuacji odpalam Filelight¹ i sprawdzam co tak niemiłosiernie pożera moją przestrzeń dyskową. Okazało się, że plik o nazwie dead.letter w katalogu domowym zajął sobie dość sporą część miejsca :

$ du dead.letter
448M dead.letter
448M total

Troche dużo jak na pojedyńczy plik

Plik ten zawierał informacje o wykonywanych zadaniach crona. Standardowo w przypadku błędu cron wysyła nam maila ze skargą. U mnie jednak nie mam skonfigurowanego ani zainstalowanego serwera poczty, ani także nie ma takiej konieczności powiadamiania. To więc cron z racji, że nie mógł wysłać mi maila, wszelkie błędy zapisywał sobie we wspomnianym pliku.

Czytając stronę man polecenia crontab, dowiemy się :

Jeśli MAILTO jest zdefiniowane, lecz puste (MAILTO=”"), to nie są wysyłane żadne listy.

Tak więc rozwiązaniem okazało się dopisanie do crontaba :

MAILTO=""

Teraz nie jest już tworzony plik dead.letter, ani też cron nie podejmuje prób powiadamiania mnie mailem.

Pakiety w Portage są segregowane tematycznie, co pozwala na przeglądanie danej kategorii w poszukiwaniu ciekawych aplikacji. Lub po prostu testowaniu przeróżnych programów. Sam w ten sposób znalazłem wiele interesujących pozycji. Oczywiście podczasz takiego przeglądania nie będziemy korzystać z polecenia emerge -s, bo na dłuższą metę staje się to bezsensowne.

W takiej sytuacji dotychczasz korzystałem z graficznej nakładki Kuroo (o której kiedyś już wspominałem), która umożliwiała mi przeglądanie pakietów wraz z ich opisami, stroną domową itd. Kuroo jednak jest troche mozolne i czasami mnie zawodzi.

Lepszym wyborem okaże się skorzystanie z pakietu opartego na GTK. Mowa o małej aplikacji porthole¹. Znajduje się ona w Portage. Wyglądem nie zachwyca, ale swoje zadanie spełnia i to znacznie szybciej.

Czasami przeglądając w ten sposób drzewo Portage, możemy natrafić na mniej znane, lecz dobre pakiety.

Initng¹ być może w niedalekiej przyszłości zastąpi standardowy sysinit. Jego główny cel to zwiększenie szybkości rozruchu systemu poprzez wielowątkowe uruchamianie usług. Narazie jednak projekt jest cały czas w wersji testowej, ale szybko się rozwija. Już teraz można się pokusić o jego przetestowanie a nawet korzystanie na codzień. Nie zalecam jednak całkowitego przejścia na initng i usunięca sysinit.

Przy testowaniu initng natrafiłem na wiele problemów i nadal nie wszystko działa wyśmienicie, i tak jakby sobie to wyobrażał. Sądzę jednak, że można doprowadzić go do jako takiej stabilności. I tym razem jest o co walczyć. Z initng udało mi się niemal dwukrotnie zredukować czas rozruchu. Obecnie mój system startuje w 23s (do KDE)!

Załączam dowód oczywiście :

Dodatkowo zyskujemy także na czasie, jeśli chodzi o zamykanie systemu. Tutaj również występuje równoległe zamykanie procesów. Gentoo wyłącza się w 7s!

Wymagane są dwa pakiety : initng oraz initng-ifiles. Ich najnowsze wersje uzyskałem z nakładki (dostępnej dzięki skryptowi layman) o nazwie initng.

Kwestia instalacji jest opisana na stronie initng², więc nie będę się powtarzał. Warto także sięgnąć do HOWTO³ na Gentoo wiki. Kilka początkowych problemów na pewno rozwiążemy czytając FAQ⁴.

Initng zapewnia nam wygodny skrypt do zarządzania usługami, działający na identycznej zasadzie jak standardowy rc-update dla sysinit’a. Za pomocą tego skryptu i ewentualnie edytując odpowiednie pliki, np. /etc/initng/default.runlevel dla runlevel’a o nazwie default, zdecydujemy o usługach jakie będą nim uruchamiane.

Zamiast wydając polecenie :

# /etc/init.d/alsasound start

Do wystartowania odpowiedniego demona w initng, użyjemy skryptu ngc :

# ngc -s alsasound

Pozostaje mi tylko zachęcić do wypróbowania i przekonania się samemu o szybkości procesu rozruchu z użyciem initng.

Lista zmian¹ jest dość pokaźna, jednak ja skupie się na tych co ciekawszych.

Pierwsza nowość która się nam zapewne rzuci w oczy, jest zmiana standardowej kolejności wyświetlania flag dla pakietów. Obecnie nie są one wszystkie sortowane alfabetycznie, lecz najpierw są umieszczane wszystkie aktywne flagi, a potem flagi wyłączone.

Jeśli ktoś był przyzwyczajony do starego schematu i chce do niego powrócić musi dodać taką linijkę do pliku /etc/make.conf :

EMERGE_DEFAULT_OPTS="--alphabetical"

Kolejna sprawa to flagi oznaczone żółtym kolorem oraz znakiem “%”. Oznacza to, że dana flaga została dodana teraz do pakietu, a dla wcześniejszych wersji tego pakietu nie była dostępna.

Ciekawe może się także okazać mapowanie kolorów. W prosty sposób możemy sobie nieco pozmieniać domyślne kolory używane przez Portage’a. W tym celu edytujemy plik /etc/portage/color.map i dodajemy kolejne definicje kolorów według schematu

bazowy_kolor=nowy_kolor

Przykładowo :

yellow=darkyellow
red=darkred
blue=lightgray
green=darkgreen

Co dam nam coś takiego :

Kolory z jakich możemy przebierać, to te zdefiniowane w pliku /usr/lib/portage/pym/output.py.

Pojawiły się pewne zmiany w definiowaniu zmiennych. Zmienne RSYNC_* zostały wycofane, a należy używać zamiast ich, jeden zmiennej o nazwie PORTAGE_RSYNC_EXTRA_OPTS. Należy wprowadzić małe zmiany do pliku /etc/make.conf u mnie są to zmiany typu :

RSYNC_EXCLUDEFROM="/etc/portage/banned_branches"
RSYNC_TIMEOUT = 300

Musiałem zmienić na :

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/banned_branches --timeout=300"

Na koniec wspomnę jeszcze o opcji parallel-fetch dzięki której podczas kompilacji, równolegle będą ściągane źródła do następnej kompilacji. W ten sposób zyskamy nieco na czasie. Chcąc korzystać z tej możliwości dodajemy do /etc/make.conf taką linijkę :

FEATURES="parallel-fetch"

Dodano nowe możliwości przechowywania logów z procesu kompilacji pakietów za pomocą emerge’a. Dotychczas można było uzsykać pełny plik log (zmienna PORT_LOGDIR) dla każdego pakietu, zawierający wszystkie informacje z kompilacji. Jednak w ten sposób łatwo można przegapić ważne informacje zawarte w ebuild i wypisywane podczasz kompilacji. Logi przechowywane w ten sposób, także bardzo szybko się rozrastały.

Teraz możemy wyciągnać najważniejsze informacje z procesu kompilacji, ostrzeżenia, informacje oraz błędy. Odpowiedzialne za ten proces są dwie nowe zmienne PORTAGE_ELOG_CLASSES, która decyduje jakie informacje zapisać do logów. Natomiast wartość zmiennej PORTAGE_ELOG_SYSTEM wpływa na to w jaki sposób i gdzie zapisywać logi. Oczywiście te zmienne ustawiamy standardowo w pliku /etc/make.conf :

PORTAGE_ELOG_CLASSES="info warn error log"
PORTAGE_ELOG_SYSTEM="save"

Teraz po każdej skończonej kompilacji uzyskamy znacznie mniejszy plik log w katalogu /var/log/portage/elog zawierający tylko najważniejsze informacje. Po więcej ustawień można zobaczyć do /etc/make.conf.example.