Dariusz [LocK] Łuksza

Prace nad programem do inżynierki zaszły już tak “daleko”, że wypadało by gdzieś ten kod przetrzymywać dla bezpieczeństwa. Dobrym dodatkowym feature’m byla by też możliwość jego wersjonowania … jako, że jakiś temu postawiłem sobie własne repo git’a (dwie (1, 2) z zamierzonych trzech części opisu instalacji zostały już opublikowane) wybór był oczywisty.

Początkowo zadanie wydawało się bardzo banalne … dodać repozytorium do gitosis i wszystko powinno się zrobić automatycznie … cóż tak niestety nie było. Dla potomności (oraz mojej często wątpliwej pamięci) postanowiłem opisać całą procedurę.

Będzie do tego potrzebna nam konfiguracja gitosis. Jako że jest ona przetrzymywana jako jedno z repozytoriów nie powinno być żadnych problemów z jej uzyskaniem. Tak więc jeżeli nie mamy już jakiejś kopi na dysku wywołujemy komendę:

git clone ssh://gitosis@server.z.gitem.org/gitosis-admin.git

Następnie edytujemy plik gitosis.conf w którym odajemy nowe repo:

[repo nazwa-nowego-repo]
owner = joe
description = opis

No i niby wygląda na to, że to wszystko … niestety nie jest tak łatwo, z tego co doświadczyłem to  gitosis wymaga, żeby każde repo posiadało osobną grupę o tej samej nazwie (możliwe, że można to jakoś przekonfigurować ale ja nie znalazłem takich informacji). Więc nie pozostaje nam nic innego jak dodać kolejną grupę:

[group nazwa-nowego-repo]
owner = joe
writable = nazwa-nowego-repo
members = joe

Zapisujemy zmiany i za pomocą git push wypychamy je na serwer … no to konfiguracje gitosis mamy za sobą. Teraz zostało nam jeszcze utworzyć repo ;>

Tak więc w lokalnym systemie tworzymy sobie nowy katalog albo wchodzimy do katalogu projektu który chcemy wrzucić do repo, w środku wywołujemy git init, następnie przy użyciu git add dodajemy wszystkie pliki do commit’a. Potem commit’ujemy zmiany do lokalnego repo (git commit -m “initial commit”) … no i teraz najważniejsze, dodajemy nasze zdalne repo:

git remote add dowolna-nazwa-repo ssh://gitosis@server.z.gitem.org/nazwa-nowego-repo.git

i tryumfalnie wypychamy wszystko na serwer

git push dowolna-nazwa-repo --all

To tyle, wszystko powinno działać … przynajmniej na razie u mnie działa ;>

Dziś lub jutro dodam wpis odnośnie aktualnego stanu wtyczki dodającej obsługę git’a dla Eclipse będzie to bardzo szybkie overview funkcjonalności których do tej pory użyłem/używałem.

UPDATE:
Wpis o git’cie i eclipse jest prawie gotowy, zostało mi jeszcze opisać branche’owanie, merge’owanie, push’owanie oraz pull’owanie i wstawić screenshot’y

UPDATE2:
Dziś git też mnie pokonał … okazało się, że aktualnie plugin nie wspiera merge’owania branche’y, a push’owanie i fetch’owanie jest zbyt skomplikowane żeby opisywać je w jednym wpisie (zwłaszcza jeżeli nie ma się z tym zbyt wiele doświadczenia). Postaram się skończyć wpis jutro (zapamiętać: jutro nigdy nie umiera ) i go opublikować.

Tak oto wygląda MacBook po tym jak dorwała się do niego para informatyków … osobiście starałem się trzymać w miarę z dala od destrukcji, ale nie odmówiłem sobie wyrwania układu karty graficznej ;>

Na powyższym zdjęciu brakuje kilku istotnych elementów  <!– @page { margin: 0.79in } P { margin-bottom: 0.08in } –>konstrukcyjnych, takich jak:

• matryca LCD
• klawisze z klawiatury (teoretycznie zachowałem je sobie w razie “W”)
• procesor (został wyrwany w celu zrobienia “wisiorka”)
• układ karty graficznej (podzielił los procesora)
• karty WiFi (myślałem, że układ Aheros’a który znajdował się w tym mac’u będzie dobrym zamiennikiem dla mojego Broadcom’a; niestety jak się przekonałem natywne wsparcie postaci ath5k dostarcza mniej funkcjonalności niż para bcm + ndiswrapper)

BTW. Dla ścisłości to nie jest mój mac … mój sprzęt ma się dobrze

W poprzednim poście de facto mało zajmowaliśmy się git’em … szczerze powiedziawszy to skonfigurowaliśmy tylko lighttpd które to później będzie nam potrzebne do uruchomienia cgit‘a czyli interfejsu www w którym będziemy mogli obejrzeć sobie nasze repo. Dziś za to zajmiemy się instalacją i konfiguracją gitosis.

Czym jest gitosis i o czego będzie nam potrzebne?

Cóż, podobnie jak sam git, gitosis jest zestawem skryptów ułatwiającym prace z repozytorium. Zestaw tych skryptów odpowiedzialny jest za kontrolę dostępu do repo jak i za sam dostęp do niego.

Jak działa gitosis?

“Integruje” się ono z serwerem SSH, “integruje się” to za wiele powiedziane, bo sshd wykorzystywane jest tylko do autoryzacji użytkowników oraz transferu danych z i do repo. Samo gitosis nie uruchamia dodatkowego daemona, jak już wspomniałem korzysta z sshd.

Jak przebiega proces autoryzacji ?

Podobnie jak w GitHub‘ie najpierw trzeba dodać nasz klucz publiczny, żebyśmy mogli zostać z autoryzowani, następnie przy każdej próbie połączenia z repo będzie on wykorzystywany do przeprowadzenia autoryzacji … nie ma w tym żadnej wielkiej filozofii, dorzycamy nasz klucz i wszystko po prostu działa.

Ok, więc może w końcu do sedna … zaczynamy od zainstalowania pakietu gitosis w systemie:

apt-get install gitosis

Proces instalacji sam utworzy w systemie konto użytkownika (standardowy login to gitosis), założy mu katalog domowy (standardowo: /srv/gitosis). Jeżeli bardzo chcemy to możemy to zmienić korzystając ze standardowej komendy usermod dla uproszczenia ja będę się posługiwał standardową nazwą użytkownika. Pozostaje nam tylko inicjalizacja i konfiguracja:

sudo -H -u gitosis gitosis-init < id_rsa.pub

Gdzie id_rsa.pub jest naszym kluczem publicznym używanym przez naszego klienta ssh … fajnie to brzmi ale co to właściwie jest ? Dokładny opis jak taki klucz sobie wygenerować (i co z nim zrobić) znajduje się tutaj. Generalnie powinien być to klucz który będzie identyfikował naszą maszynę z której będziemy się łączyć do repozytorium (tj. klucz prywatny i publiczny powinny być zapisane w katalogu ~/.ssh na twoim desktopie/laptopie, tylko klucz publiczny w celu instalacji go w konfiguracji gitosis powinieneś skopiować na serwer na którym instalujesz repozytorium). Powyższa komęda powinna zainicjalizować repozytorium git/gitosis oraz dodać wskazany klucz publiczny jako klucz administratora. Jeżeli mamy szczęście to po wykonaniu poniżeszej komędy na naszym desktopie/laptopie (tj. na tym na którym znajduje się para ~/.ssh/id_rsa i ~/.ssh/id_rsa.pub):

git clone gitosis@adres_serwera:gitosis-admin.git

Jeżeli powyższa komenda nie wykona się poprawnie (jak to było w moim przypadku) zmuszeni jesteśmy skonfigurować gitosis ręcznie. W tym celu udajemy musimy przeedytować plik /srv/gitosis/.ssh/authorized_keys (tak wiem, że nie powinno się go edytować … ale co nam pozostaje ?) i zmienić “domyślny” login na identyczny z tym podanym w komentarzu do naszego klucza prywatnego (to jest to co podaliśmy za przełącznikiem -C podczas jego tworzenia), wartość klucza publicznego (to jest ten dziwny ciąg znaków za ssh-rsa) oraz na samym końcu ponownie wstawiamy wartość z naszego komentarza. Po wykonaniu tych zmian i ich zapisaniu ponownie próbujemy sklonować repozytorium z konfiguracją (czyli jeszcze raz wydajemy poprzednią komendę) … jeżeli znowu nie wykona się poprawnie … cóż czasem trzeba sobie radzić samemu

Ok, zakładam że w końcu uda się pobrać z serwera konfigurację z serwera … tak, na prawdę gitosis przechowuje swoją konfigurację w formie jednego z repozytoriów. Jest to dość wygodne, gdyż nie wymusza na nas logowania się na serwer celem zmiany konfiguracji (w wypadku dodania użytkownika repozytorium, czy też nowego projektu). W każdej chwili możemy sobie ta konfigurację pobrać, zmodyfikować, “wepchnąć” z powrotem i usunąć jak dla mnie bomba .

Co do samej konfiguracji to składa się ona z 2 rzeczy:

• pliku z konfiguracją (znajdują się tam definicje repozytoriów, grup i praw dostępu)
• katalogu z kluczami publicznymi użytkowników

W katalogu keydir/ znajdują się klucze publiczne użytkowników, w postaci:

uzywany_login.pub

najczęściej login ma postać adresu email, więc przykładowy plik dla użytkownika wlodek@luksza.org będzie się nazywał wlodek@luksza.org.pub … jest to niezmiernie skomplikowane, nieprawdaż

W przypadku kiedy chcemy dodać nowego użytkownika bądź repozytorium musimy przeedytować plik gitosis.conf, jego opis można znaleźć tutaj. W przypadku użytkowników należy pamiętać o zgodności nawy użytkownika z nazwą pliku zawierającą jego klucz publiczny. Dodatkowo warto wspomnieć o tym, że dla każdego repozytorium możemy zdefiniować właściciela (parametr owner ) oraz opis (description), są to przydatne parametry zwłaszcza podczas eksploracji repozytorium przy użyciu cgit‘a czy też gitweb‘a.

Kiedy już wykonamy wszystkie zmiany commit’ujemy je do lokalnego repo, a potem wypychamy do głównego:

git commit -a
git push

W ten prosty sposób administrujemy repozytorium git’a zarządzanym przez gitosis

BTW. Chyba szykuje się nam zmiana na miejscu domyślnego repo Eclipse Fundation możliwe, że nowe repo będzie obsługiwane przez git’a, “pierwsze” takie przesłanki można znaleźć tutaj.

Jakiś czas temu pisałem jak za pomocą git’a i pendirve’a można w łatwy sposób zabezpieczyć się przed utratą projektu. Dziś przedstawię bardziej skomplikowane podejście, a mianowicie postawimy repozytorium git’a na serwerze. W moich założeniach takie repozytorium nie będzie dostępnie publicznie (w przeciwieństwie do rozwiązania jakie na starcie proponuje GitHub; mają też rozwiązanie płatne w którym to możemy mieć  prywatne repo, ale ja wole mieć je u siebie ).

Moje oczekiwania od takiego repo są następujące:

• dostępność do repo z każdego zakątka świata (czyli serwer musi być dostępny szeroko pojętej sieci)
• możliwość dostępu do repo tylko dla wybranych użytkowników
• możliwość przeglądania repo z poziomu www
• bezpieczeństwo stosowanego rozwiązania (https, ssh)

Jakie wybrałem oprogramowanie ?

• systemem bazowym będzie Debian (znany, lubiany i standardowy linux)
• gitosis (prosty soft do hostowania repozytorium git’a z równie prostą kontrolą dostępu, IMO rozwiązanie w sam raz do moich potrzeb)
• lighttpd (mały i szybki httpd)
• mod_ssl oraz mod_auth do wyżej wymienionego httpd
• cgit odpowiednik gitweb’a ale moim zdaniem ładniejszy i bardziej przejrzysty

We własnym zakresie trzeba zadbać o system bazowy, oraz jego konfigurację . Zakładam, że Debian jest już zainstalowany, skonfigurowany, zabezpieczony oraz podpięty do sieci.

Zaczynamy od instalacji i konfiguracji lighttpd

apt-get install lighttpd apache2-utils

Pakiet apache2-utils będzie nam potrzebny do wygenerowania hash‘a hasła potrzebnego do mod_auth (swoją drogą system pakietowania debiana coraz bardziej mnie zadziwia … nie rozumiem po co w zależnościach do tego pakietu znajduje się libmysqlclient …). Po zainstalowaniu włączamy dwa interesujące nas moduły:

lighttpd-enable-mod auth
lighttpd-enable-mod ssl

Oraz przechodzimy do konfiguracji zarówno httpd jak i modułów. Zaczniemy od mod_auth, czyli edytujemy pliczek /etc/lighttpd/conf-enabled/05-auth.conf, w którym to wybieramy backend (czyli algorytm szyfrowania haseł oraz miejsce ich zapisu) oraz konfigurujemy miejsca do których dostęp będzie strzeżony hasłem. Po modyfikacjach plik konfiguracyjny powinien wyglądać mniej więcej tak:

## Authentication for lighttpd
##
## Documentation: /usr/share/doc/lighttpd-doc/authentication.txt.gz
##                http://www.lighttpd.net/documentation/authentication.html
server.modules                += ( "mod_auth" )
# htdigest jest najmocniejszym dostepnym "algorytmem" szyfrujacym
auth.backend                   = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/lighttpd-htdigest.user"
 
auth.require                 = ( "/" =>
                                     (
                                       "method"  => "digest",
                                       "realm"   => "secure content",
                                       "require" => "valid-user"
                                      )
                                )

Opcja auth.require zawiera tylko jeden element, którym jest root serwera httpd, czyli dostęp do dowolnego pliku na serwerze będzie chroniony hasłem. Warto tutaj wspomnieć, że hash hasła zostanie posolony wartością w realm, dzięki temu uzyskujemy prosty mechanizm kontroli dostępu (tj. gdybyśmy mieli dwa zasoby z różnymi wartościami w realm, każdego użytkownika który powinien posiadać dostęp do obu powinniśmy dodać osobno). Teraz wystarczy tylko dodać użytkownika:

htdigest -c /etc/lighttpd/lighttpd-htdigest.user 'secure content' user_name

Po wydaniu tej komendy zostaniemy poproszeni o podanie oraz potwierdzenie hasła dla tego użytkownika.

Po skonfigurowaniu mod_auth przechodzimy do konfiguracji mod_ssl, w tym celu edytujemy /etc/lighttpd/conf-enabled/10-ssl.conf. Ja zdecydowałem się udostępniać usługę http tylko na porcie 443 z szyfrowaniem (czyli popularny https ), więc w konfiguracji mod_ssl wskazałem na którym dokładnie adresie IP oraz na jakim porcie ma nasłuchiwać daemon; plik konfiguracyjny wygląda mniej więcej tak:

## lighttpd support for SSLv2 and SSLv3
##
## Documentation: /usr/share/doc/lighttpd-doc/ssl.txt
##      http://www.lighttpd.net/documentation/ssl.html
 
#### SSL engine
$SERVER["socket"] == "111.222.3.4:443" {
ssl.engine                  = "enable"
ssl.pemfile                 = "/etc/lighttpd/server.pem"
}

następnie generujemy certyfikat self-signed dla naszego serwera:

openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes

Który to kopujemy do /etc/lighttpd/server.pem.

Ostatnią częścią konfiguracji lighttpd będzie ogólna konfiguracja serwera, czyli edytujemy plik
/etc/lighttpd/lihttpd.conf. W którym to odkomentowujemy tylko linie:

server.bind = "localhost"

Spowoduje to, że port 80 zostanie otwarty tylko na interfejsie loopback, co w konsekwencji prowadzi do tego, że wszystkie połączenia (z sieci) do portu 80 będą odrzucane (za to akceptowane będą połączenia do portu 443, zgodnie z konfiguracją w pliku 10-ssl.conf).

Na razie to wszystko w kwestii konfiguracji lighttpd, wrócimy jeszcze do niej podczas konfiguracji cgit’a. W następnej części zajmiemy się konfiguracją gitosis.

PS. Tutaj jest część druga.

Kilka dni temu JetBrains udostępniło okrojona wersje (ładnie nazwaną Community Edition) swojego IDE dla Javy. Jako że nigdy nie miałem do czynienia z InteliJ postanowiłem zassać ową darmową wersję i sprawdzić jak się spisuje.

Niestety, używam dość egzotycznego window managera który zwie się Awesome. Posiada on funkcjonalność auto organizacji okien na pulpicie co jak się okazuje nie podoba się Javie 1.5 wzwyż. Winę za to ponosi zmieniony w JRE 1.5 backend do komunikacji z X-Window, JRE do wersji 1.4 korzystało z Motif, natomiast w późniejszych z Xtoolkit/XAWT które to nie jest kompatybilne z ICCCM (cokolwiek to znaczy ). Warto tutaj wspomnieć ze pośrednio może tutaj tez być winne JetBrains gdyż ciągle korzystają z AWT, a nie Swing‘a …

Rozwiązania ?
Są dwa. Pierwsze bardziej drastyczne uruchamiać InteliJ z wykorzystaniem JRE 1.4 – tego nie próbowałem ale teoretycznie powinno zadziałać. Drugie rozwiązanie posiada pewien haczyk, gdyż (jak się domyślam) 64-bitowa wersja Javy nie posiada wsparcia dla Motif; osoby posiadające 64-bitowe maszyny i systemy operacyjne z 64bitowa maszyna wirtualna ustawiona jako domyślną muszą dodatkowo zassać i gdzieś umieścić wersje 32-bitowa JDK/JRE. Oprócz 32-bitowej maszyny wirtualnej musimy dodać zmienna środowiskową AWT_TOOLKIT ustawiona na MToolkit. Ja zmodyfikowałem sobie plik bin/idea.sh dodając w linii 59 taki oto fragment:

# fixes for Awesome WM
export AWT_TOOLKIT="MToolkit"
IDEA_JDK="/ścieżka/do/jdk-x86"

Cala historia zaczęła się parę dni temu, kiedy to zapragnąłem sobie mieć prywatny serwerek do hostowania własnych nie publicznych projektów (do publicznych używam już github‘a).

Jako, że serwer jest dostępny publicznie, a hostować ma nie publiczne projekty przydało by się go trochę zabezpieczyć … z administrowaniem serwerami nie miałem wiele wspólnego, ale od czego jest Google

W sieci znajduje się kilka opisów co można poprawić w standardowym Debianie żeby zwiększyć jego bezpieczeństwo. Oprócz samych zabezpiczeń warto tez być na bierząco informowanym o stanie systemu. Informacje takie możne nam dostarczyć program logcheck (wraz z logcheck-database), tylko ze jakoś te informacje muszą do nas trafić, tutaj z pomocą przychodzi … poczta elektroniczna, czyli popularne e-maile .

Wszystko było by fajnie gdyby nie to, że w momencie wysyłania wiadomości Debian usilnie korzysta z lokalnego MTA (tj. mail transport aget … domyślnie jest to exim4), co nie do końca jest fajne (jest to osobny daemon, dodatkowe otwarte porty itp.) zwłaszcza jeżeli tuz obok stoi dedykowany serwer pocztowy.

W tej sytuacji instalujemy heirloom-mailx, programik ten (po odpowiednim skonfigurowaniu) pozwala używać dowolnego zewnętrznego serwera pocztowego podczas wywoływania systemowej komendy /usr/bin/mail. Potrzebna konfiguracje umieszczamy na końcu pliku /etc/nail.rc (nie mylić z /etc/mail.rc) … kiedy chcemy żeby dany użytkownik posiadał odrębną konfiguracje, to musimy wymedytować plik ~/mail.rc

set smtp-use-starttls
set from=user@jakis.host.org
set smtp=smtp.jakis.host.org
set smtp-auth-user=user@jakis.host.org
set auth-login=user@jakis.host.org
set smtp-auth-password=supertrudneitajnehaslo
set ssl-verify=ignore

Teraz możemy przetestować nasza konfiguracje wywołując:

mail nasz-adres@nasz-server.org

Jeżeli coś nie działa to zostaniemy o tym poinformowani stosownym komunikatem … BTW. jeżeli chcemy sobie debugować możemy wykorzystać przełącznik -d (jak debug ) , z tym ze należy tutaj wspomnieć, że dodanie tego przełącznika powoduje wypisanie na ekran wiadomości i … nie powoduje jej wysyłania (sic!).

Dlaczego o tym pisze ? Bo dziś zmarnowałem ładnych parę godzin(sic!) żeby się do tego dogooglac … najpierw żeby znaleźć ta paczkę, potem zęby odpowiednio skonfigurować (tutaj szczególne podziękowania należą się przełącznikowi -d …).

Oto prosty sposób na przeniesienie repozytorium GIT na pendrive, czy inną przenośna pamięć.

1. Dla uproszczenia dodamy sobie nasze wymienne repozytorium do pliku /etc/fstab w tym celu:

   ls -l /dev/disk/by-uuid # odnajdujemy na liście nasz urządzenie,
   w moim przypadku sdb1
   mkdir /mnt/git-gsoc # tworzymy odpowiedni katalog do montowania
   chown lock:lock /mnt/git-gsoc # zmieniamy właściciela

   przy użyciu ulubionego edytora edytujemy /etc/fstab. Dodajemy następującą linie:

   UUID=<uuid z pierszego polecenia> /mnt/git-gsoc	<system plików> user,rw,noauto 0 0

2. Teraz przydało by się zawartość naszego obecnego repo przenieść do nowego …  wystarczy skopiować główny katalog repozytorium (prostota git’a)

Mając już sklonowane repozytorium przydał by się jeszcze jakiś skrypt który za nas wykona zbędne rzeczy (tj. podmontuje pamięć, odpali git-deamon, a potem po sobie posprząta ).

#! /usr/bin/bash
# Copyrighted, 2009
# Developed by Dariusz Luksza <dariusz[at]luksza[dot]org>
# License: GPL v2
 
case "$1" in
connect)
	echo -n Montuje urzadzenie ...
mount /mnt/git-gsoc &> /dev/null
if  [ "$?" -eq "0" ]
then
		echo " DONE."
		echo -n Startuje git gaemona ...
		git daemon --export-all --base-path=/mnt/git-gsoc/backup --detach \
			--pid-file=/mnt/git-gsoc/git-daemon.pid --enable=receive-pack --listen=localhost
		echo " DONE."
exit 0
else
		echo Wystapil blad podczas montowania, sprawdz urzadzenie!
exit 1
	fi
	;;
disconnect)
if [ -e /mnt/git-gsoc/git-daemon.pid ]
then
		echo -n Zatrzymuje git daemona ...
kill `cat /mnt/git-gsoc/git-daemon.pid`
rm /mnt/git-gsoc/git-daemon.pid
		echo " DONE."
		echo -n Odmontowuje urzadzenie ...
sync
		umount /mnt/git-gsoc/
		echo " DONE."
exit 0
else
		echo Daemon nie zostal uruchomiany
		exit 1
	fi
	;;
*)
	echo Uzycie:
	echo "    " $0 "[connect|disconnect]"
	;;

Oczywiście każdy sam musi sobie dostosować ścieżki dostępu

Kiedy mamy już wszystko poustawiane warto by sprawdzić czy wszytko działa poprawnie tj. uruchamiamy powyższy skrypt z parametrem connect i po chwili powinniśmy mieć uruchomionego daemona GITa. Teraz wystarczy do naszego lokalnego repozytorium dodać to które właśnie utworzyliśmy:

git remote add backup git://localhost/<nazwa repo>

i używać uchwytu backup

Miłej zabawy ;>

Chyba nadeszła ta chwila kiedy to w końcu trzeba zmienić środowisko graficzne … po prawie pięciu latach spędzonych na Fvwm-Crystal nadeszła chyba pora na zmianę.

Jakie są przyczyny ? Osobiścnie nie narzekam na Crystala jest:

• mały
• szybki
• poręczny (jeżeli się już nauczy podstawowych skrótów)

Ale posiada jedną bardzo wielką wadę … wszystko było by OK gdyby nie to, że zachciało się mi podłączyć zewnętrzny monitor. W tym momencie Crystal (konkretniej mówiąc pages czyli przestrzenie robocze) wariuje, wyświetlane jest jednocześnie “półtorej” przestrzeni roboczej (tj. cała aktywa i kawałek następnej). Próbowałem nawet restartować i przeładowywać recepturełale to jeszcze pogorszyło efekt …

Tak więc staję znowu przed pytaniem “jakiego WMa wybrać”. Nie jest to dla mnie pytanie proste … bo szczerze mówiąc nie znam nic innego Jedno wiem na pewno, nie będzie to ani KDE ani Gnome.

Dla ścisłości … jakie wytyczne musi spełniać nowe środowisko:

• możliwość konfiguracji do 12 przestrzeni roboczych i przełączanie się między nimi przez <alt>+F[1-12] (lub <win>+F[1-12])
• możliwość przełączenia się pomiędzy dwoma sąsiadującymi przestrzeniami przy pomocy <alt>+[ i <alt>+]
• możliwość przełączenia się pomiędzy dwoma ostatnio używanymi przestrzeniami za pomocą <alt>+<esc>
• możliwość ciągłego podglądu wszystkich przestrzeni roboczych tj. tego co jest na nich odpalone (w Crystalu mam na prawej krawędzi pasek który reprezentuje wszystkie przestrzenie robocze oraz aplikacje na nich odpalone oczywiście umożliwia on również przełączanie pomiędzy przestrzeniami)
• brak żadnych pasków zadań i menu (jedno menu “ekranowe” tj. po kliknięciu LMB w pulpit)
• możliwość zdefiniowania aplikacji które mają się odpalać automatycznie
• możliwość maksymalizacji okna poprzez <alt>+=
• możliwość zdefiniowania od jakiego rozmiaru ma być zmaksymalizowane okno
• nie powinno się rozjeżdżać po podłączeniu zewnętrznego monitora

oczywiście wszystkie te funkcjonalności nie muszą być od razu dostępne ale dane środowisko powinno być na tyle konfigurowalne żeby umożliwić mi ustawienie wszystkich tych opcji ale też nie chcę tonąć w plikach i skryptach konfiguracyjnych …

Cóż, poszukiwania czas zacząć … może ktoś pod powie parę ciekawych środowisk ? ;>

Parę dni temu postanowiłem zgrać moją skromną kolekcję płyt audio do formatu MPC. Nie chcąc marnować czasu (i zaśmiecać systemu zbędnym softem), postanowiłem napisać sobie mały i prosty skrycik w Python’ie. Założenia

• prostota
• automatyczność (wkładam płytę odpalam skrypt i zapominam … )
• zapis wyjściowych plików w pewnym ustalonym schemacie katalogów (wykonawca, nazwa albumu i utworu pisana camel case’em dodatkowo nazwa utworu poprzedzona jego numerem oraz praw dostępu: 400 (dla utworów_ i 500 (albumu))
• automatyczne pobieranie informacji o utworach bez konieczności ich przepisywania (tj. wykorzystanie CDDB, a konkretnie cddb-py)

Oto efekt (należy pamiętać żeby podmienić baseDir !):

#! /usr/bin/python
 
"""
cda2mpc, Copyrighted, 2009
Ripps directly from CD audio to musepack (mpc) format.
Developed by Dariusz Luksza 
License: GPL v2
"""
 
import CDDB, DiscID, re
from sys import stdout
from string import capitalize
from os import chmod, makedirs as mkdir
from subprocess import Popen, PIPE, call
 
baseDir = '/home/lock/muzyka/'
 
def camelCase(value):
    return "".join([capitalize(w) for w in re.split(re.compile("[ _]?"), value)])
 
print 'Getting CDDB info ...',
stdout.flush()
cdrom = DiscID.open()
discId = DiscID.disc_id(cdrom)
 
(queryStatus, queryInfo) = CDDB.query(discId)
 
if isinstance(queryInfo, list):
	queryInfo = queryInfo[0]
 
(readStatus, readInfo) = CDDB.read(queryInfo['category'], queryInfo['disc_id'])
 
album = queryInfo['title']
splitAt = album.index('/')
 
artist = album[:splitAt - 1]
album = album[splitAt + 2:]
print ' DONE.'
 
print 'Starting to encoding:', artist, '-', album
 
saveDir = baseDir + camelCase(artist) + '/' + camelCase(album) + '/'
try:
	mkdir(saveDir, 0700)
except OSError:
	pass
 
for i in range(discId[1]):
	title = readInfo['TTITLE' + `i`]
	wavTrack = saveDir + 'track.wav'
	fileName = saveDir + `i + 1` + '-' +camelCase(title) + '.mpc'
	print '\tEncode track:', title , ' (', `i+1`, '/', discId[1], ')'
	print '\t\tStage 1 (wave) ...',
	stdout.flush()
 
	p = Popen(['cdparanoia', '-q', `i + 1`, wavTrack], stdout=PIPE)
	p.wait()
	if p.returncode is not 0:
		print ' ERROR!!'
		continue
	print ' DONE.'
	print '\t\tStage 2 (mpc) ...',
 
	stdout.flush()
	mpcCmd = ['mppenc', '--deleteinput', '--xtreme', '--silent', '--artist',
			artist, '--album', album, '--title', title, wavTrack, fileName]
	p = Popen(mpcCmd, stdout=PIPE, stderr=PIPE)
	p.wait()
	if p.returncode is not 0:
		print ' ERROR!'
		continue
	chmod(fileName, 0400)
	print " DONE.\n\tCOMPLETED."
 
chmod(saveDir, 500)
print 'COMPLETED.'
call('eject')

Pommed jest deamon’em umożliwiającym korzytanie z mac’owych klawiszy funkcyjnych (tych od ściszania czy rozjaśniania ekranu lub też od manipulacji głośnością) obsługuje również wbudowane czujniki oraz zmianę intensywności podświetlenia klawiatury … oraz potrafi przyciemnić ekran kiedy się odłączy zasilanie … właśnie ta funkcjonalność wzbudziła moje zainteresowanie …

Dlaczego, skoro już obsługiwanie jest zdarzenie odłączenia od zasilania, nie obsługiwane jest zdarzenie zamknięcia klapki (tzw. LID). IMHO przejście w stan uśpienia było by najrozsądniejszym rozwiązaniem reakcji na zamknięcie przez użytkownika wieka laptopa.

Chwila grzebania w kodzie programu ujawniła, że takie rozwiązanie nie jest intuicyjne dla autora aplikacji, lub z jakiś powodów zostało odrzucone w procesie developmentu … domyślnie pommed w wersji 1.25 w reakcji na zamknięcie klapki … wyłączy podświetlenie klawiatury, oczywiście jeżeli takowe jest obecne w tam modelu mac’a. W przypadku kiedy nie posiadamy podświetlanej klawiatury zdarzenia LID są  ignorowane … szkoda bo można to wykorzystać w inny sposób.

Tutaj dostępny jest patch dodający możliwość konfiguracji zdarzenia LID. Domyślnie po opuszczeniu klapki zostanie wykonana komenda pm-suspend. W gruncie rzeczy może to być dowolna komenda która piszemy w pliku konfiguracyjnym … to chyba na tyle.

Ten sam patch wysłałem również do autora aplikacji … może poprawi moje błędy (bo w C nie pisałem już od wieków ;>) i jakoś dodatkowo rozwinie ta funkcjonalność.