Dariusz [LocK] Łuksza

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"

Mimo, ze oficjalne ogłoszenie wyników GSoC09 odbyło się prawie dwa miesiące temu, dla mnie google’owe lato z kodowaniem zakończyło się dopiero parę dni temu kiedy to kurier dostarczył do mnie paczkę z koszulka i certyfikatem.

Co do samego projektu, to niestety nie udało mi się go skończyć w wyznaczonym terminie. Osobiście stopień zaawansowania oceniam na 75-80%. Mimo to Reinhard (mój mentor) uznał, że wykonałem na tyle dobrą pracę że ukończyłem pozytywnie GSoC.

Koniec Summer of Code nie oznacza dla mnie końca współpracy z developerami Cocoon’a, zwłaszcza, że nie wykonałem w pełni stawianych sobie celów. Dodatkowo na horyzoncie pojawiły się nowe interesujące pomysły na rozwój modułu monitorującego trzecią wersję Cocoon‘a.

Ostatnio pisząc o Summer of Code wspominałem o artykule traktującym o Spring JMX, miał on się ukazać w ciągu 2-3 tygodni … cóż nie udało się ale nie wydaje mi się by jego los był przesądzony . Wszystko jest ciągle kwestią czasu … jest to jedna z rzeczy którą chciałem zrealizować w czasie GSoC i ciągle pozostaje na mojej (dość, długiej(sic!) już) liście TODO.

Zapomniałem o jednej bardzo ważnej rzeczy … 90% napisanego przeze mnie kodu podczas GSoC znajduje się już w repozytorium ASF, a dokładniej mówiąc to jest tutaj. Natomiast całość kodu dostępna jest w archiwum znajdującym się pod koniec tej listy.

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 …).

Today I publish newest version of cda2mc on github.

This version contains 2 new features:

1. it is possible to add CD information manually if CDDB does not contains information about it
2. if CDDB contains multiple entry’s for that particular CD you can chose one from list with one you want to use