Interfejs do wysyłania smsów via sms-pl
Napisałem sobie prosty skrypt do wysyłania smsów poprzez program sms-pl (dostępny w repozytoriach). Jego konfiguracja opiera się na wprowadzeniu dwóch linijek do pliku /etc/smsrc w których zawrzemy nasz login i hasło do płatnej bramki sms (sposób edycji znajdziemy w dokumentacji programu), możliwe także jest skorzystanie z bezpłatnych bramek sms! Po odpowiednim skonfigurowaniu sms-pl możemy już korzystać z poniższego skryptu: (w przypadku korzystania z innej bramki niż miastoplusa należy wyedytować jedną linijkę w skrypcie)
#!/bin/bash
numer=$(kdialog --inputbox "Wyślij sms pod numer:")
tresc=$(kdialog --textinputbox "Wprowadź treść:")
kdialog --passivepopup "Wysyłam wiadomość..." 4
sms -g miastoplusa -n "$numer" -m "$tresc"
if [ $? == 1 ]; then
kdialog --sorry "Sms nie wysłany, spróbuj ponownie"
else
kdialog --passivepopup "Wiadomość wysłana!" 3
fi
exit 0
Zamieniąc odpowiednio kdialog na xdialog lub dialog skrypt będzie działać też w innych środowiskach graficznych niż KDE (możliwe że konieczna będzie drobna zmiana skryptu).
Wiem że to banalne, wiem że są odpowiednie programy do robienia tego samego. Wolę jednak korzystać z własnych rozwiązań.
PowerTOP - zarządzanie energią
Każdy posiadacz laptopa chciałby, aby jego maszyna pracowała jak najdłużej i jak najefektywniej. Nie ma nic bardziej denerwującego, niż komunikat "Stan krytyczny: 5 minut" w czasie pracy nad ważnym dokumentem//wpisem na joggera w przypływie weny :-). Programiści Intela wyszli naprzeciw użytkownikom i stworzyli mały i bardzo pomocny program - PowerTOP.
PowerTOP (strona domowa) to aplikacja, która ma za zadanie badać słabe punkty Twojego systemu (pod względem poboru energii). Wygląd i sposób działania aplikacji można porównać do popularnego 'top' (patrz screen). Sposób działania programu opiera się na pobieraniu z przestrzeni użytkownika oraz jądra stosownych informacji na temat m.in. ACPI, konfiguracji jądra, modułów i przekazywaniu wyniku testów na ekranie w formie mini-porad. PowerTOP informuje nas o czasie działania procesora w każdym ze stanów (throttling//scalling), ilości wzbudzeń procesora ze stanu uśpionego w ciągu sekundy, poborze mocy w watach, sumarycznej i procentowej ilość wzbudzeń procesora przez dane moduły//funkcje oraz, co najciekawsze, wyświetla mini-porady dotyczące optymalizacji systemu.
Aby nasz laptop działał sprawniej i dłużej, musimy uważać na:
- 'C-state' był jak najwyższy. Idealna sytuacja to taka, w której procesor pracuje w stanie C3 bądź C4 w około 90-95%. (mowa o laptopie korzystającym z zasilania bateryjnego).
- Wzbudzenia ze stanu uśpienia mają być jak najrzadsze. Wg. Intela możliwym jest osiągnięcie 3 wzbudzeń na sekundę... W praktyce nigdy nie zszedłem poniżej 60.
- Procesy//moduły które powodują przerwania i wybudzają nasz CPU - jeśli np. nie korzystamy z sieci wifi możemy wyrzucić moduł przez 'rmmod'. Pełna lista procesów i modułów pozwoli nam podjąć dalsze działania.
Polecam także kierowanie się sugestiami zawartymi na dole PowerTOP.
Wymierne korzyści? Po dostosowaniu mojego sprzętu według zaleceń PowerTOP zyskałem 10 minut więcej na baterii podstawowej (przed modyfikacją - 2:21, po modyfikacji - 2:31) oraz 17 minut na baterii dodatkowej (przed modyfikacją - 6:10 po modyfikacji - 6:27) (stany podane z odczytu kpowersave w 10 minut po włączeniu komputera i ustabilizowaniu się pracy dysku). Tak więc mogę korzystać z mojego sprzętu już nie 8 godzin i 31 minut ale 8 godzin i 58 minut bez przerwy. Może w przypadku tak długich czasów 27 minut nie gra roli, lecz dla użytkowników laptopów marki ACER czy też tańszych modeli ASUS//HP takie zwiększenie czasu pracy to duża różnica. Dla ciekawskich - tak wygląda to u mnie (stan dla jednej baterii):
Cn Avg residency P-states (frequencies)
C0 (CPU aktywny) ( 2,6%)
C1 0,0ms ( 0,0%) 1100 MHz ( 0,0%)
C2 13,1ms ( 5,4%) 1000 MHz ( 0,0%)
C3 15,0ms (92,0%) 900 MHz ( 0,0%)
600 MHz (100,0%)
Wakeups-from-idle per second : 65,5 interval: 15,0s
Użycie zasilania (szacunek ACPI): 7,2W (2,3 godzin)
Najczęstsze powody wybudzenia:
30,9% ( 10,8) artsd : schedule_timeout (process_timeout)
9,5% ( 3,3) fnfxd : do_nanosleep (hrtimer_wakeup)
7,8% ( 2,7) psi : schedule_timeout (process_timeout)
Instalacja? Polecam pobrać i skompilować program ze strony producenta, bądź też leniuchy mogą użyć apt'a i pozyskać starą wersję PowerTOP:
# apt-get install powertop
Enjoy!
psDooM - zarządzaj swoimi procesami!
psDooM to monitor systemowy dla systemów Linuksowych. Z użytkownikiem komunikuje się poprzez wygodny i ładny interfejs graficzny (screen obok). Posiada funkcjonalność programów takich jak 'ps', 'renice' oraz oczywiście 'kill' :-).
psDooM (strona projektu) to implementacja XDoom jako środowiska do zarządzania procesami. Twórca projektu David Koppenhofer, nudząc się zapewne w pracy, przeglądał kod źródłowy Doom'a i dopisał do niego kilka funkcji bazujących na wywołaniach systemowych. Dlatego też w psDooM każdy potworek to określony proces z przyporządkowanym PID'em oraz nazwą. Jak widać na screenie powyżej nasze procesy zbyt grzeczne nie są... 'xv' potrafi dać w kość.
Niestety, psDooM posiada wiele błędów. Jeden z takich opiszę. Wyobraźmy sobie wielkiego i groźnego Basha szarżującego na nas i zasypującego gradem kul. My, w panicznej ucieczce chowamy się za pierwszy z brzegu proces, który całkowitym przypadkiem nazywa się 'init'. Kule groźnego Basha dosięgnęły niewinnego 'inita'. Chyba nie trzeba pisać co się stało z systemem? :-)
Dodatkowo: w systemie z wieloma uruchomionymi procesami psDooM staje się symulatorem hipermarketu w dzień świąteczny. Dodatkowym problemem staje się szef.. Bo jak mu wytłumaczyć, że właśnie zarządzamy największym klastrem w firmie a nie gramy w DooM'a? :-)
Z plusów psDooM'a autor wymienia:
- Stopniowe zarządzanie procesem. Admin może tylko zranić proces dając mu do zrozumienia, że zrobił coś źle.
- Młodzi admini mogą dostawać do ręki mniej niszczycielskie bronie, tym samym nie powodując szkód w najważniejszych procesach. Prawdziwi admini dysponują BFG.
- Bardzo obciążane systemy zyskują mechanizm samoregulacji. W przypadku zbyt zatłoczonej planszy potwory zabijają same siebie pozostawiając na placu boju najlepsze (najmocniejsze) procesy. Selekcja naturalna w GNU/Linux! Nigdy więcej zarządzania obciążeniem!
- SysAdmini mogą kooperować robiąc 'ustawki' na co gorsze procesy. Paczka Adminów może w końcu razem radzić sobie ze złą sytuacją na serwerach!
Cóż, nie można odebrać Davidowi dobrego poczucia humoru :-). psDooM to tylko ciekawostka i swoisty żart ze strony programisty//admina GNU/Linux. Pamiętajcie - używanie go w swoich systemach może prowadzić do niestabilności Twojego systemu. Zresztą oboje wiemy - po to go uruchamiasz ;-).
Oto strona, która opisuje sposób instalacji psDooM. A ja spadam. Chyba firefox-bin za bardzo urósł i się do Amaroka mi dobiera... EOT.
ENJOY! :-) ps. Niestety, psDooM to projekt zapomniany, David już się nim nie zajmuje. W chwili wolnego czasu chciałbym kontynuować jego pracę, dobrałem się do kodu źródłowego DooM'a (świetnie opisany!) oraz zaczynam rozumieć mechanizmy, które zaimplementował David. Może psDooM nie umrze - pomysł jest genialny! Zainteresowani?
DCOP - komunikacja międzyprocesowa
Zastanawialiście się kiedyś, czemu Iceweasel tak chętnie 'wskakuje' na pasek kicker, Opera tak ładnie ładuje się do tray'a a Wasz ulubiony player muzyczny oferuje Wam wygodne sterowanie głośnością czy też paskiem postępu utworu przez mini-interfejs? Desktop Communication Protocol [DCOP] to protokół umożliwiający komunikację między procesami w środowisku KDE3. W momencie gdy piszę te słowa KDE4 zbliża się wielkimi krokami (3 miesiące), a wraz z nim całkowite odejście od DCOP w kierunku D-BUS SYSTEM, więc póki jeszcze czas postaram się opisać to cudowne narzędzie - ot dla potomnych :-).
Przyjrzyjmy się zatem interfejsowi DCOP, a konkretniej - klientem DCOP. Używając skonfigurowanego dopełniania poleceń w Bashu możemy przeglądać strukturę aplikacji w bardzo wygodny sposób.
$ dcop kaccess khotkeys kmix ksmserver kcookiejar kicker knotify kwin kded klauncher konqueror-6695 kdesktop klipper konsole-9344
Widzimy tutaj wszystkie programy korzystające z interfejsu DCOP do wymiany informacji. Chcemy "skontaktować się" z kmix odpowiadającym za mikser systemowy. Wpiszmy zatem:
$ dcop kmix kmix Mixer0 kmix-mainwindow#1 Mixer1 MainApplication-Interface qt
Otrzymaliśmy wykaz wszystkich funkcji, jakie oferuje nam kmix. Posiadam w systemie dwie karty dźwiękowe, zatem mam do dyspozycji Mixer0 oraz Mixer1. Sprawdzę, czy Mixer0 to moja podstawowa karta dźwiękowa.
$ dcop kmix Mixer0 mixerName Intel 82801DB-ICH4
Tak jest. Zacznijmy zatem "magię". Mixer0 oferuje nam takie funkcje:
$ dcop kmix Mixer0 absoluteVolume int mute setMute absoluteVolumeMax interfaces open setRecordSource absoluteVolumeMin isAvailableDevice QCStringList setVolume bool isRecordSource QString toggleMasterMute close long setAbsoluteVolume toggleMute decreaseVolume masterMute setBalance void functions masterVolume setMasterMute volume increaseVolume mixerName setMasterVolume
I już po krótkiej zabawie możemy (konsolowo!) zmieniać głośność, wyciszać kartę czy też nawet zamknąć program. Aby dowiedzieć się, w jaki sposób używać wybranej funkcji wpisujemy:
$ dcop kmix Mixer0 QCStringList interfaces() QCStringList functions() void setVolume(int deviceidx,int percentage) void setMasterVolume(int percentage) void increaseVolume(int deviceidx) void decreaseVolume(int deviceidx) int volume(int deviceidx) int masterVolume() void setAbsoluteVolume(int deviceidx,long int absoluteVolume) long int absoluteVolume(int deviceidx) long int absoluteVolumeMin(int deviceidx) long int absoluteVolumeMax(int deviceidx) void setMute(int deviceidx,bool on) void setMasterMute(bool on) void toggleMute(int deviceidx) void toggleMasterMute() bool mute(int deviceidx) bool masterMute() void setRecordSource(int deviceidx,bool on) bool isRecordSource(int deviceidx) void setBalance(int balance) bool isAvailableDevice(int deviceidx) QString mixerName() int open() int close()
Skorzystajmy z tego i wyciszmy naszą kartę:
$ dcop kmix Mixer0 setMute 0 1
I ponownie ją włączmy:
$ dcop kmix Mixer0 setMute 0 0
Zabawy z DCOP nie ograniczają się tylko do tak prostych spraw, jak sterowanie głośnością czy zamykanie aplikacji. Pokaże Wam teraz, jak można użyć DCOP do oskryptowania własnego "wyświetlacza" tekstów aktualnego utworu na ekranie. Potrzebujemy do tego uruchomionego Amaroka.
$ dcop amarok player
Nie wklejam tutaj wyniku tej komendy, gdyż jest on zbyt duży :-). Amarok daje nam dostęp do tak wielkiej ilości funkcji poprzez interfejs DCOP, że z wykorzystaniem języków skryptowych możemy napisać własny "wrapper" czy też mini-interfejs dla tej kobyłki. Zobaczmy na kilka przykładów:
$ dcop amarok player nowPlaying LOST HORIZON - World Through My Fateless Eyes
$ dcop amarok player currentTime 0:48
$ dcop amarok player lyrics
Ostatnia komenda pokaże nam tekst aktualnie odtwarzanego utworu (o ile mamy skonfigurowany moduł Lyrics w skryptach Amaroka). Jak zatem pokazać to cudo na ekranie? Skorzystamy z Conky :-). Najpierw stwórzmy skrypt "lyrics"
$ cat /bin/lyrics
#!/bin/bash
dcop amarok > /dev/null
if [ $? != 0 ]; then
echo "Amarok nie jest włączony";
else
dcop amarok player lyrics
fi
exit 0
I podepnijmy go pod Amaroka (linijka do wklejenia w Conky'm, wyjście poddane obróbce "śmieci" xml'a).:
${execi 10 lyrics | tail -n +2 | sed "s/'/'/g"}
Tym oto prostym sposobem zmusiliśmy Conky do ukazywania tekstu aktualnego utworu. Podobnie możemy konfigurować swoje skrypty odwołujące się do danego programu (co widać w skrypcie "lyrics" w instrukcji warunkowej 'if'. Ale czy to koniec?
Oczywiście że nie! Czemu by nie użyć DCOP jako systemu powiadomień (np. o nowej poczcie, albo o wydarzeniu)? To się da zrobić!
$ dcop knotify default notify eventname appname 'Witaj swiecie!' '' '' 2 0
Opis poszczególnych parametrów funkcji "notify" uzyskamy poprzez:
$ dcop knotify Notify | grep notify void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level) void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level,int winId) void notify(QString event,QString fromApp,QString text,QString sound,QString file,int present,int level,int winId,int eventId)
Jak widzicie interfejs DCOP jest bardzo wygodny dla programistów języków skryptowych (np. jak w moim przypadku - Basha). Sprawia, że moje programy otrzymują nowe funkcjonalności i działają w różnych warunkach (np. potrafią sprawdzać, czy dany program jest uruchomiony czy nie, jeśli nie wyświetlać graficzne powiadomienie itp.). DCOP posiada jeszcze jeden, ogromny plus. Jest bardzo szybki. W moim odczucie o wiele szybszy od D-BUS. Nie rozumiem czemu twórcy KDE4 zrezygnowali z DCOP. Obiecują interfejs zastępczy, wrapper zapytań. Mówią że będzie kompatybilnie. Już to widzę... Ja od DCOP niezbyt chcę odchodzić. I na koniec kilka ciekawostek:
$ dcop kdesktop KDesktopIface runAutoStart
W ten sposób KDE uruchamia wbudowany Autostart.
$ dcop kdesktop KBackgroundIface setWallpaper
Wasz program ma zmieniać domyślną tapetę?
$ dcop kdesktop KDesktopIface setIconsEnabled
Ukrywać ikony?
$ dcop knotify default notify eventname appname 'Gorion TVN-Style HACK3d!!!!111' '' '' 2 0
I straszyć kumpla? :-)) Życzę Wam miłej zabawy w odkrywaniu możliwości tego systemu!
I jak zwykle: ENJOY! Bo Linux to masa zabawy :-)
Pytanie na marginesie: czy Gnome posiada podobny interfejs? Czy używa D-BUS? Przyznaję - nie wiem bo nie używam od bardzo dawna.
Wywołania systemowe w systemie GNU/Linux
Na początku krótkie wyjaśnienie tego czym jest wywołanie systemowe w ogólnym tego słowa znaczeniu. Wywołanie systemowe (System Call) to funkcja używana przez proces w celu zażądania od systemu operacyjnego (a ściślej - jądra) określonej usługi. Wywołania systemowe są generowane przez przerwania w samym programie (procesie).
Nowoczesne procesory przetwarzają instrukcje w kilkudziesięciu trybach dostępu (różniących się poziomem bezpieczeństwa oraz np. czasem trwania). W systemie GNU/Linux, definiujemy tylko dwa tryby - Tryb Użytkownika oraz Tryb Nadzorcy. Poziomy dostępu zostały stworzone po to, aby system mógł w prosty i jasny sposób decydować o przyznaniu dostępu do zasobów dla procesu. Jądro systemu operacyjnego GNU/Linux uruchamiane jest zawsze w uprzywilejowanym trybie - z oczywistej przyczyny - musi przyznawać dostęp do warstwy sprzętowej dla aplikacji (warstwy programowej), zarządzać przerwaniami, zmieniać tryb dostępu procesora czy też zarządzać pamięcią (tutaj przychodzi ku pomocy sheduler, którego opisałem całkiem niedawno).
Jednak system (kernel) sam w sobie nie potrafi kontrolować mechanizmu zmiany trybu dostępu. Aby zapewnić obsługę sytuacji, w której mnie uprzywilejowany kod transferuje swoje dane (lub jakiekolwiek wygenerowane przez niego) do wyżej uprzywilejowanego kodu potrzebujemy małego "włamu" i przełamania zabezpieczeń. Oczywiście - nie dosłownie. Nie możemy dopuścić do hipotetycznej sytuacji, w które mniej uprzywilejowany proces stara się wymusić na procesie o wyższym priorytecie np. błąd stosu. Standardowo system operacyjny dostarczany jest z biblioteką obsługującą zdarzenia i pośredniczącą między jądrem a procesem. W GNU/Linux tą biblioteką jest libc (Biblioteka C). To ona zarządza i nadzoruje wszystkie niskopoziomowe przepływy informacji pomiędzy procesami i kernelem, a także dzięki niej odbywa się "magiczna zamiana" trybu pracy procesora (z mniej uprzywilejowanego na bardziej lub na odwrót).
Posiadamy więc bibliotekę, którą użytkownik może wywołać w swoim programie i skorzystać z jej funkcji, aby przekazać "coś" "gdzieś" (mówiąc kolokwialnie:)). Przyjrzyjmy się zatem troszkę bliżej libc a w szczególności tematem wywołań systemowych. Jako przykład zatem - kawałek kodu odpowiedzialny za ustawienie UID w GNU/Linuksie.
_syscall1(int,setuid,uid_t,uid); _setuid: subl $4,%exp pushl %ebx movzwl 12(%esp),%eax movl %eax,4(%esp) movl $23,%eax movl 4(%esp),%ebx int $0x80 movl %eax,%edx testl %edx,%edx jge L2 negl %edx movl %edx,_errno movl $-1,%eax popl %ebx addl $4,%esp ret L2: movl %edx,%eax popl %ebx addl $4,%esp ret
Jak widać - operujemy assemblerem. Każda funkcja posiada co najmniej 2 argumenty: numer wywołania systemowego i rodzaj (definicję) działania tegoż wywołania. Każda funkcja wywołania systemowego biblioteki libc zwalnia przerwanie 0x80. Z tego adresu możemy pobrać (np. strace'm) wszystkie wywołania systemowe dowolnego programu. Gdy przerwanie zwolni się (najczęściej po określonym w jądrze "tiku"(czasie)) kod wyjścia jest pobierany z pamięci i możliwy do odczytania przez inną funkcję, bądź też przez wymieniony strace. Argumenty przekazywane są w rejestrach w następującej kolejności: eax, ebx, ecx, edx, edi, esi, ebp. Numer funkcji systemowej jest przekazywany w eax.
Całą pracę za wywołania przejmuje system przerwań. Po wywołaniu funkcji system_call() "praca" rozpoczyna się w 'adresie wejścia', który jest zdefiniowany w arch/i386/kernel/entry. Niestety, rutyny te zapisane są w języku niezrozumiałym dla przeciętnego człowieka. Stąd też krótki algorytm, jako ilustracja tego co dzieje się w czasie wywołania systemowego:
zwraca typ system_call(sys_call_number, sys_call_arguments)
{
Zapisz rejestry procesu;
Sprawdź, czy sys_call_number reprezentuje prawdziwą wartość wywołania;
jeśli nie pokaż błąd
w innym wypadku
{
Sprawdź flagę PF_TRACESYS wybranego procesu;
Wywołaj planistę (jeśli potrzebny);
Przekaż sygnały;
Swolnij rejestry procesu;
}
}
I krótkie wyjaśnienie//opis opisanego algorytmu. Dwie zmienne są przekazywane do rutyny: Sys_call_number odwołuje się do wcześniej zdefiniowanej liczby identyfikującej wywołanie systemowe. Sys_call_arguments przekazuje kolejne argumenty dla wywołania (jeśli potrzebne). Zapisanie rejestrów jest potrzebne, gdyż bez tego wywołanie planisty w późniejszym czasie mogłoby skutkować SIGSEGV. Następnie - sprawdzenie czy numer wywołania jest prawidłowy. Flaga PF_TRACESYS pozwala stwierdzić, czy dany proces nie ma procesu-rodzica. Tutaj wchodzi do gry funkcja syscall_trace (oto jej kod źródłowy arch/i386/kernel/ptrace.c). Jeśli wykryje rodzica przesyła mu SIGTRAP, wcześniej ustawiając procesowi potomnemu flagę TASK_STOPPED. Tutaj wkracza nasz dzielny planista i robi co do niego należy - zajmuje się pamięcią obu procesów (bądź jednego, jeśli proces nie miał rodzica). Jeśli wysłaniu sygnału SIGTRAP i pracy planisty proces dostał//wysłał jakikolwiek sygnał zostaje on przetworzony w tym momencie, po czym przywracane są rejestry.
I na koniec przykład użycia. Oto kawałek strace dla /bin/true:
brk(0) = 0x804a308 brk(0x804b308) = 0x804b308 brk(0x804c000) = 0x804c000 _exit(0)
Przepiękny pogląd na funkcję brk(), która poprzez przerwanie (wywołanie systemowe) odwołała się do pamięci (adres 0x804a308). Program bez praw dostępu do pamięci (przynajmniej bezpośrednio - nie działający w trybie uprzywilejowanym) poprzez System Call odwołał się do jądra, aby ten dał mu mały fragment wolnej pamięci.
Celowo nie opisuję sposobu tworzenia własnych wywołań systemowych. Zainteresowani zajrzą zapewne do Google, a niezainteresowani w końcu skończą czytać ten nudny wpis :-).
I tą oto jogg-notką powracam do żywych :-) Witajcie już oficjalnie! Następny odcinek mam już praktycznie napisany - a w nim... DCOP - jedna z rzeczy za które kocham KDE! :-) Stay Tuned!
