Shutter, czyli Linux i screenshoty

Przyznaję, że jeśli chodzi o zrzuty ekranu pod Linuksem, to nie znałem do tej pory dobrego narzędzia. Znaczy jest scrot[1], który jest prosty, bardzo mały, lekki i wywoływany z CLI, i którego użycie w wersji podstawowej, czyli cd /tmp && scrot -d 8 było proste do zapamiętania, ale… jak lubię CLI, tak w przypadku grafiki to zdecydowanie nie jest to, co tygrysy lubią najbardziej. Tym bardziej, że zwykle robię zrzuty przeglądarki, więc trzeba było dodatkowo przyciąć, wymazać, wykadrować… Czyli w ruch szedł GIMP.

Zrzuty ekranu robię na tyle rzadko, że nigdy nie szukałem dokładniej programu do screenshotów i przypuszczałem, że po prostu takiego nie ma. Okazuje się, że się myliłem. Kumpel z pracy pokazał mi genialny program o nazwie shutter[2]. Nie jest lekki (łącznie z zależnościami pobrał kilkadziesiąt MB danych), ale za to jest w pełni graficzny, minimalizuje się do traya, pozwala na robienie screenshotów zarówno całego pulpitu, tylko wybranego okna programu jak i wcześniej zaznaczonego obszaru (odpada konieczność kadrowania).

Po wykonaniu zrzutu ekranu, można go zapisać na dysku (wspierane wszystkie popularne formaty grafiki), wysłać na jeden z wielu dostępnych serwisów do publikowania obrazków, zapisać na zdalnym hoście przy pomocy FTP lub wysłać do innego programu do dalszej obróbki. Jeśli zajdzie potrzeba, bo sporo funkcji jest wbudowanych np. w postaci pluginów. Jest też wsparcie dla sesji screenshotów podobno z automatycznym numerowaniem, ale nie używam, więc nie testowałem.

W zasadzie, gdyby działało wszystko, co jest opisane na stronie, to nie potrzebowałbym nie potrzebuję niczego innego do robienia i obróbki screenshotów. 🙂 , niestety, w mojej wersji (0.88.3, Debian Wheezy) nie widzę narzędzia do cenzurowania/ukrywania danych, a czasami z tego korzystam. Możliwe, że pojawiło się dopiero w nowszej wersji Tak czy inaczej Polecam zapoznanie się z programem shutter każdemu, kto potrzebuje robić screenshoty pod Linuksem – zdecydowanie interesujący i dopracowany kawałek softu.

UPDATE: Aby działała edycja screenshotów (w tym cenzurowanie), konieczne jest jeszcze doinstalowanie biblioteki Perla: apt-get install libgoo-canvas-perl.

[1] Instalacja przez apt-get install scrot.

[2] Instalacja (Debian) to oczywiście apt-get install shutter.

Uruchomienie mikrofonu w Banana Pi

Jedną z przewag Banana Pi nad Raspberry Pi jest wbudowany mikrofon. Na początku nie byłem pewien, czy to mikrofon czy samo gniazdo. Jest mikrofon.

Mikrofon

Źródło: http://www.publicdomainpictures.net/view-image.php?image=25258

W przypadku użycia dedykowanej dystrybucji Bananian, wystarczy zainstalować pakiety alsa-base alsa-tools alsa-utils, poprawić w pliku /etc/asound.conf card 1 na card 0 i… uruchomić alsamixer, żeby zwiększyć głośność i… to wszystko. Czyli praktycznie z pudełka działa.

Czyli:

apt-get install alsa-base alsa-tools alsa-utilscat /etc/asound.confpcm.!default {        type hw        card 0 # for headphone, turn 1 to 0        device 0}ctl.!default {        type hw        card 0 # for headphone, turn 1 to 0}

Najprostszy sposób na „streamowanie” dźwięku z mikrofonu to:

ssh user@IP_banana_pi 'arecord -f S16_LE -' | aplay

Ale to raczej doraźne i do szybkiego zdalnego sprawdzenia. Muszę rozejrzeć się za czymś porządniejszym, z kompresją do mp3/ogg, uwierzytelnianiem i najchętniej w formie demona, który potrafi streamować po sieci. Dam znać jak znajdę, a tymczasem podpowiedzi mile widziane.

Testowanie szybkości kluczy Zabbix agenta

Było tak, że jeden z kluczy w Zabbiksie działał wolno. Nawet: bardzo wolno. Ile czasu może się wykonywać proste sprawdzenie wersji programu typu chef-client -v, nawet na umiarkowanie dobitym systemie? Zainteresowani znajdą odpowiedź na końcu wpisu[1], dość powiedzieć, że czasami załączał się timeout po stronie zabbix agent. Problem został rozwiązany w sposób najdoskonalszy, czyli poprzez zrzucanie wartości z crona do pliku, i czytanie jej z pliku, ale niesmak pozostał. Poza niesmakiem, pozostało pytanie które jeszcze klucze są nieoptymalne?

Ponieważ na ten moment Zabbix nie daje możliwości sprawdzenia statystyk czasu zapytań dla poszczególnych kluczy, wykonałem małą protezę w postaci skryptu w Perlu, który odpyta danego hosta o wszystkie klucze kilka(naście) razy i policzy dla nich statystyki. Wklejka poniżej.

 

Skrypt przyjmuje dokładnie jeden parametr – hosta na którym będzie przeprowadzać test. Poza tym, wymaga wszystkich kluczy dla danego hosta, które ma testować, w pliku określonym w zmiennej $file. Na końcu wyświetli łączny czas wykonania zdefiniowanej ilości zapytań dla każdego klucza wyrażony w sekundach oraz sam klucz. Czytaj: pewnie chcesz przepuścić wynik przez sort -n. 😉

Parę rzeczy, które wyszły w trakcie pisania tego skryptu lub których się nauczyłem (w sumie gdyby nie one, to nie powstałby ten wpis):

Pętla sprawdzające N razy wszystkie klucze po kolei jest dokładniejsza od pętli, która sprawdza kolejno wszystkie klucze N razy każdy. Chodzi o rozkład obciążanie na maszynie, w tym drugim przypadku jest większa szansa, że któryś klucz trafi w nietypowe obciążenie maszyny.

Dokumentacja do modułu Time::HiRes jest… taka sobie. Można to zrobić prościej, jak wyżej. Początkowo kombinowałem ze sprintf oraz clock_gettime(CLOCK_REALTIME);

Może zastanawiać, skąd mnożenie przez 1000000. Otóż chodzi o bug z zapisem liczb zmiennoprzecinkowych (kojarzyłem to raczej z ośmiobitowców i dzielenia, nie wiem czy słusznie…):

perl -e '$a=1415907504.646884; $b=1415907504.603042; $d=$a-$b; print $d,$/'

vs.

perl -e '$a=1415907504.646884*1000000; $b=1415907504.603042*1000000; $d=($a-$b)/1000000; print $d,$/'

Że tak zacytuję real programmers use integer. 😉

Na koniec niezła wiadomość: jest szansa, że w przyszłości Zabbix będzie miał coś w stylu MySQLowego slowloga, czyli nie będzie trzeba robić testów na poszczególnych hostach, tylko będzie wbudowane narzędzie do wykrywania wolnych zapytań. Można głosować na ten feature. 😉

Specjalne podziękowania za uwagi i wyjaśnienia dla Tona z #perl @ IRCnet (thanks Ton!).

I wracając do pytania o nieoptymalne klucze z początku wpisu – tylko nieszczęsny chef-client okazał się być czarną owcą. Pozostałe klucze, choć czasem wymagają uruchomienia Perla lub kilku poleceń w Bashu, wykonywały się w zdecydowanie przyzwoitym czasie, grubo poniżej sekundy.

[1] Wykonuje się nawet cbanq cvęganśpvr frxhaq (rot13)! Bo na tyle ustawiony był timeout…