KShutDown – graficzne narzędzie do zamykania, usypiania oraz hibernacji systemu

zainstaluj gpoweroff jak msz gnome :)

Nie pozostaje nic innego, jak czekać na gotowe KDE Frameworks 5…

Jaka dystrybucja?
To nie są bezpośrednie zależności kshutdown. Jeśli kshutdown został zbudowany z bibliotekami KDE to nie ma się co dziwić :D W takiej konfiguracji kshutdown wymaga kdebase4-runtime, kdebase4-workspace i klika innych. Stąd tyle się tego nazbierało… Tak się składa, że w drugą stronę zależności wyglądają tak samo :) Są tacy co mają tylko KDE/Qt bez niczego "na gtk". Dla nich instalacja programu wymagającego gnome będzie taką samą męką…
Jeśli używasz Gnome, skompiluj kshutdown bez bibliotek KDE, tylko z Qt ;)

W Debianie 7.1 z zainstalowanym środowiskiem GNOME instalacja kshutdown bez pakietów polecanych wiąże się ze ściągnięciem 100 pakietów o wadzę 90 MB (260 po rozpakowaniu) w tym np. phonon czy vlc-nox. :)

Podziekuj za to paczkującym.

W Archu instalacja gshutdown wymaga jeszcze więcej. Gshutdown wymaga libglade, który wymaga gtk2, który wymaga poza masą bibliotek używanych tylko w programach GTK i Gnome, tony śmieci jak biblioteki do obsługi JPEG2000 czy libcups do drukowania. GShutdown czy KShutdown praktycznie nic z tego co jest zależnością w dystrybucjach nie potrzebują i jeśli zbudować im biblioteki tylko z tym co potrzebują wielkość zależności byłaby niewielka… problem w tym, że w Linuksie programy nie są dostarczane z bibliotekami, a polegają na tym co jest w systemie, dlatego wszystko jest budowane z maksymalnymi możliwościami i drzewko zależności rozrasta się do gigantycznych rozmiarów – jeśli używasz KDE te zależności się dublują i nie obchodzi Cię ich rozmiar, bo to zależności dla większości oprogramowania… wtedy denerwuje Cię instalacja programu z Gnome wymagającego tonę śmieci które użyjesz tylko z tym programem, a on ich nawet nie obsługuje (jednak te zależności są zbudowane tak, żeby działać z masą softu… tylko tobie niepotrzebnego bo używasz innych). Jeśli używasz Gnome i programów GTK to masz tak samo (masę bibliotek masz zainstalowanych ale one się dublują w prawie każdym programie więc na ich wielkość nie zwracasz uwagi, jednak instalując mini programik jak kshutdown zabija Cię informacja o ilości danych do ściągnięcia , bo dystrybucje te zależności kompilują z maksymalną siecią zależności i nie wiedzą, że będziesz chciał używać tylko tak prostej aplikacji i nie przytną Ci tego na miarę).

To co piszesz o zależnościach to święta prawda, ale cały czas aplikacje KDE są dużo większym wrzodem na dupie dla użytkowników jakiegokolwiek DE opartego na GTK, niż w drugą stronę.

Z ciekawości uruchomiłem sobie obraz instalacyjny archa i porównałem kshutdown (+ 1056.55 MiB po rozpakowaniu) z gshutdown (+ 172.13 MiB po rozpakowaniu). To sześciokrotnie więcej zależności!

To tylko mały przykład. Bardzo miło ze strony twórców kshutdown że można ich kod skompilować w oparciu o czyste QT, wtedy zależności są naprawde znośne, problem w tym że to nie jest częsta praktyka w repozytoriach i nie wszystkie programy dają taką możliwość.

To nie takie proste – po prostu w Archu jest o tyle dziwnie z pakietami, że te 172MB pakietów powiązanych z gshutdown nie wymaga… instalacji Xów, które i tak musisz zainstalować, żeby z bibliotek skorzystać w wypadku po prostu pakietów KDE podpięta jest zależność od Xów i innych pakietów, które i tak musisz mieć zainstalowanych w systemie (a przy instalacji w Archu z gnome musisz instalować ręcznie oddzielnie). Dla przykładu całe KDE (razem z programami nieobowiązkowymi jak Amarok itp.) w pakietach Archa ma 250 MB, a reszta z tego GB to pakiety jak Xy (ponad 200 MB) i inne. W wypadku Gnome to są podobne ilości danych tylko akurat w Archu inne osoby zajmują się paczkami i nie dodają zależności rzeczy niezbędnych, ale logicznie zainstalowanych już w systemie.

Ale to oznacza, że program nie potrzebuje tylu zależności więc zależności są nieprawidłowo ustalone.

Pewnie tak, to już inna sprawa. W archu, jest jeden worek o nazwie kdebase-workspace na którym bazuje sporo pakietów, więc zależności są potwornie monolityczne. Ale od czego mamy pacman -Rdd

Nie – zupełnie nie to oznacza. Program A wymaga biblioteki X, podobnie jak program B, ale zupełnie innej części, z innymi możliwościami itd. i osoba pakująca ma problem dopasuje bibliotekę X do potrzeb programu A, aby były minimalne zależności biblioteki od innych bibliotek/programów to program B nie zadziała. Mając wiele programów korzystających z jednej biblioteki (a nie jak w Windows/MacOS/Android/… każda aplikacja ma własną kopię każdej biblioteki), możesz ją tylko uzależnić od wszystkiego co tylko jakiś program może potrzebować, aby była to wersja biblioteki uniwersalna. Ogólnie jest wyjście – albo olbrzymie zależności i współdzielenie bibliotek, albo minimalne zależności bibliotek i każdy program ma swoje własne wersję biblioteki (nie ma mowy o współdzieleniu).

"możesz ją tylko uzależnić od wszystkiego co tylko jakiś program może potrzebować, aby była to wersja biblioteki uniwersalna. "

Chodzi Ci o to, że biblioteka X musi być uzależniona od wszystkiego do czego się gdziekolwiek w kodzie odwołuje? Fakt, że mając inne rozwiązania otwarte do wykorzystania, większość będzie wolała użyć ich zamiast wymyślać koło od nowa i pewnie stąd te rozrastające się zależności.
Mimo wszystko rozwiązanie typu Click jakie wymyśla Canonical nie jest moim zdaniem lepsze. Będzie ono fajne i użyteczne, szczególnie do dostarczania komercyjnego oprogramowania, ale mam nadzieję, że ani trochę nie naruszy dotychczasowego sytemu dostarczania pakietów programów otwarto-źródłowych.

W praktyce – tak musi. Po pierwsze w Linuksowych systemach masz zasadę: nie dubluj kodu i jeśli ktoś już napisał bibliotekę do czegoś to ją do tego wykorzystaj, a nie pisz nowy kod do tego samego, a jeśli korzystasz z kodu innych bibliotek to musisz* do tych bibliotek linkować. Jeśli linkujesz już to jesteś uzależniony.

* no dobra możesz też dynamicznie ładować biblioteki jak pluginy przez dlopen() i pobierać ręcznie wskaźniki na wszystkie funkcje jakich używasz, ale zważywszy na dużą ilość bezsensownie napisanego dodatkowego kodu (pomijam już problem z brakiem dlopen i innymi nazwami bibliotek dynamicznych w windowsie), który jest podatny na błędy w czasie runtime przez literówkę (kompilator nie będzie ostrzegał), to na dodatek mocno utrudnia debuggowanie aplikacji. Nie możesz tego uznać za sensowną alternatywę.

"kompiluj kshutdown bez bibliotek KDE, tylko z Qt ;)"

To po co te wszystkie zależności, skoro program ich nie używa? Może tylko dlatego, aby w main.cpp napisać KApplication zamiast QApplication? ;)

Gdybyś zajrzał na stronę programu to być się nie pytał tutaj. http://kshutdown.sourceforge.net/README.html#kdev…

Akurat na podanej stronie nie opisano różnicy w działania obu wersji. Ale domyślam się, że cała zależność od kdelibs potrzebna jest do integracji programu ze środowiskiem KDE.

Supported Functions/Platforms

Tu jest.

Dokładnie :)
Albo
sleep 1800 && killall clementine

Odnośnie odtwarzacza to grając cover piosenki, która startuje od razu nie dając szans na równe rozpoczęcie grania napisałem sobie skrypt…

#!/bin/bash
mpc -h 192.168.1.102 stop
echo "3"
sleep 1
echo "2"
sleep 1
echo "1"
sleep 1
mpc -h 192.168.1.102 play 66

~/.bash_rc:
alias mpccountdown='mpc -h 192.168.1.102 stop && for k in 3 2 1; do echo $k; sleep 1; done && mpc -h 192.168.1.102 play $1'

$ mpccountdown 66

Możesz mi powiedzieć po co ten sleep? Samo "shutdown -h +120" (lub zamiast +120 minut napisać po prostu godzinę o której ma to zrobić jak czyli przykładowo shutdown -h 23:05) wydaje się lepszym pomysłem.

Dlaczego lepszym? Wygląd nie czyni skryptu lepszym (przynajmniej na takim poziomie, kiedy nie trzeba go 'utrzymywać'), jeżeli wszystko działa tak jak chciał, to nie ma lepszego rozwiądania.

Jest bardziej czytelny, nie wymaga pipeowania, nie zapomni o zadaniu po wyłączeniu przypadkiem konsoli (w przypadku podanego przykładu tak będzie i trzeba by to wpisać w skrypt i uruchomić go w tle (dopisać "&" po skrypcie)). Samo shoutdown jest po prostu lepszym sposobem – nie, że korzystanie z uruchomienia warunkowego jak "&&" nie spełniało swojego zadania, bo spełnia, ale jest wyjściem gorszym (zarówno w zapisie, jak i w działaniu, bo trzeba pamiętać o wysyłaniu tego polecenia w tło, aby zamknięcie terminala konsoli nie odwoływało zaplanowanego zamknięcia).

Dzięki, nie wiedziałem, że można w ten sposób używać shutdown :)

Strasznie komplikujesz sobie życie z tym 60*60*2=7200 i widać, że nigdy nie widziałeś man sleep. Gdybyś widział, to wiedziałbyś, że można prościej czyli:
sleep 2h

Szkoda, że nie ma jednostki milisekund. Oraz że tylko niektóre implementacje obsługują ułamki dziesiętne jako milisekundy, i tak mając problemy z lokalizacją i robiąc problemy przy przecinku i kropce. Napisałby ktoś wreszcie to polecenie porządnie…

MaszDowna.

Screeny: Gniot odpalony na XFCE… świętokradztwo ;)