Panorama

Gdy ostatnio
szalałem z aparatem
, to zrobiłem też kilka zdjęć z okna, do
panoramy. Słyszałem kiedyś o jakimś narzędziu do składania panoramy
z takich zdjęć, więc chciałem spróbować.

Spróbowałem dopiero dziś, z nudów, gdy mi Internet padł. W narzędziach
zainstalowanego GIMPa nic odpowiedniego nie znalazłem, więc poszukałem
poldkiem wśród pakietów PLD. Znalazłem Hugina
i autopano-sift.
Żeby to zainstalować musiałem poczekać na powrót sieci, ale, na szczęście, nie
trwało to długo.

Na początku Hugin się sypał, dopiero po uaktualnieniu paru bibliotek
przestał rzucać Segmentation Fault. Pierwsze co mi się rzuciło w oczy, to
przerażająca liczba przycisków i opcji. Niewiele z tego rozumiałem, więc
po prostu klikałem gdzie popadnie. O dziwo, udało mi się w ten sposób uzyskać
jakąś panoramę. W kiepskiej rozdzielczości i z dużą ilością nicości, ale
coś wyszło. Podłubałem jeszcze opcjami które udało mi się zrozumieć,
wygenerowałem coś w dużej rozdzielczości, przyciąłem GIMPem i oto, co mi wyszło:

panorama.jpg

Fajna zabawka z tego Hugina. Od razu widać, że lepszy efekt uzyskało by się
ręcznym, a przede wszystkim stałym ustawieniem ekspozycji (chociaż pewnie
i to można jakoś w Huginie skorygować), bo automat zrobił każde zdjęcie w nieco
innych kolorach i jasności. Ale i tak, efekt ostateczny mnie zaskoczył. Bardzo
pozytywnie.

Niegrzeczni PeeLDowcy, niegrzeczni…

Jeden niegrzecznych PeeLDowiec znalazł na SourceForge programik gnaughty. Pochwalił się na
pld@chat.chrome.pl i zaraz uznano, że do tego speca trzeba
zrobić, bo w PLD nie może być takich braków. Spec oczywiście powstał i zasilił
repozytorium PLD. Ciekawe kiedy ten pakiecik trafi na oficjalne FTP…
Pakiety porn-get i pornview już tam są.

Jogger umiera…

Jogger umiera. To fakt. I nie chodzi tylko o pady serwera. Zaczyna się
kończyć zapas punktów, których kiedyś miał u mnie sporo. I zdaje się,
że to samo odczuwa wielu innych Joggerowiczów. Punkty znikają z każdym
ficzerem którego nie ma, a akurat by mi się przydał, z każdym padem, z każdą
chwilą bezradności, gdy coś jest nie tak i nie ma kogo o to męczyć, a przede
wszystkim, z każdą ciekawą osobą, która z Joggera rezygnuje. Gdy Joggerowa
społeczność się wykrusza, to coraz mniej mnie tu trzyma. Zaczynam się poważnie
zastanawiać nad przeniesieniem się gdzie indziej…

Możliwości są generalnie dwie: postawić własnego bloga (może być na
gotowym oprogramowaniu), albo skorzystać z istniejącego serwisu. Oba
rozwiązania są dla mnie kuszące – własny blog to więcej możliwości
dostosowania jego do swoich potrzeb i ulepszania go, gotowy serwis to
zwolnienie z części administratorskiej roboty i możliwość zaistnienia
w jakiejś społeczności. Szczególnie to ostatnie jest istotne w Joggerze i to
ostatnie ciągnie mnie w kierunku LiveJournal.

Na LiveJournal mam nawet od jakiegoś czasu konto, służy mi do śledzenia
wpisów na jakiś tamtejszych blogach. LJ jest w dużej mierze tym, czym mógłby
być idealny Jogger. Poza dostępem przez Jabbera, którego LJ nie ma. Ma za to
dużą społeczność, udokumentowane API, ekipę która tego pilnuję, a nawet
udostępnione źródła i wiele innych. Ma też pewnie sporo upierdliwości, ale to
znajdzie się wszędzie. Mnie najbardziej zniechęca to, że za część ficzerów, na
których mi zależy (np. możliwość zmieniania szablonów i podpięcia pod własną
domenę), trzeba zapłacić. Niewiele, ale zawsze. Przykre szczególnie, że
jeszcze nie wiem, czy LJ to na pewno to czego chcę.

Rozglądałem się też nad systemami które mógłbym postawić u siebie.
Wordpressa nie chcę, bo wszyscy tego używają ;-). W ogóle, nie
chciałbym żadnego PHP, czy MySQL na swoim serwerku instalować. Rozglądałem się
za rozwiązaniami Pythonowymi, ale nic nie powaliło mnie na kolana.

Jest jeszcze jedno założenie którego będę się trzymał przy wyborze nowego
systemu pod bloga: muszę być w stanie do tego dorobić podstawową
funkcjonalność Joggerową: proste w użyciu śledzenie wpisów i wątków przez
Jabbera. Bez tego IMHO przenosiny nie mają sensu. Ale mam już pewien pomysł,
który powinno się dać zrealizować, łatwiej lub trudniej, w większości systemów
blogowych.

No cóż, na razie jeszcze tu zostanę… ale jak długo? A może mnie jeszcze
Jogger czymś zaskoczy? …albo lenistwo zrobi swoje.

Admin łajza

Lagi na łączu, strzałka do góry (historia poleceń basha) oraz
nieostrożność i problem gotowy – rm * w katalogu
z ważnymi plikami. Na szczęście nie było w nich nic ostatnio zmieniane,
a i Bacula się spisał. W ciągu kilku minut plik wróciły na miejsce.
:-)

Tylko czemu akurat w ciągu tych paru minut graficzka postanowiła mi zrobić
sesje zdjęciową? Potem narzeka, że minę na zdjęciach mam jakąś niewesołą…

Po nocce

Wczoraj znowu rozpierdziel w firmie. Tym razem przemeblowanie serwerowni.
Firma znalazła kupca na szafę rackową, a że w niej akurat stał nasz sprzęt, to
trzeba było wszystko poprzestawiać do stojaków (które, swoją drogą, mają w tej
serwerowni większy sens niż szafy). Do roboty przyszedłem na 15:00, żeby od
16-tej zacząć. Kolega miał do tego czasu opisać mi wszystkie połączenia (4
switche 24-portowe, z dziesięć serwerów, ponad dwie setki gniazd na
patch-panelach i cała masa połączeń). Nie zdążył, więc robiliśmy to razem
jeszcze z dwie godzinki. Potem było rozbieranie starych szaf, składanie
i wstawianie nowych stojaków, przekładanie patch-paneli z rozszytymi setkami
par itp. atrakcje. W końcu wstawianie sprzętu na nowe miejsce i podłączanie
wszystkiego tak aby zadziałało (oczywiście od razu działać nie chciało).
Wyszliśmy (brudni i śmierdzący, bo w budynku wodę na noc wyłaczają) z firmy
o 3:25. A niektórzy byli w pracy od 8:00.

Dzisiaj rano, normalnie od 8:00, też jakiś admin w firmie się przydał.
Jeden ma chorobowe, zostało nas dwóch. To uzgodniłem z kuplem, co wczoraj od
rana siedział, że ja przyjdę na tę ósmą, a w południe się zamienimy. Więc
przespałem się 3 godzinki, łyknąłem kofeinę z puszki (Booster — taka
podróba Red Bulla z Plusa, za grosze) i, niewiele czyściejszy niż przed
wyjściem z serwerowni, podobnie śmierdządzy i ledwo przytomny, pojechałem do
roboty.

W pracy oczywiście okazało się że parę rzeczy nie działa, ileś innych
działa, ale są podłączone tam, gdzie nie powinny itp. Latałem więc między
serwerowaniami (budynki oddalone o jakieś 500m), z serwerowni do swojego
pokoju, rozszyłem jeszcze parę kabelków na patch-panelu… i o 11-tej jakoś
się uspokoiło. Obiecałem jeszcze coś komuś sprawdzić, więc posiedziałem
jeszcze do wpół do pierwszej, ale do domu wróciłem sporo wcześniej niż
normalnie. Ufff…

W domu wreszcie mogłem się doprowadzić do porządku. Pospać to teraz bym
sobie i tak nie pospał (w dzień mi nie wychodzi), więc, mając tę chwilkę
wolnego, męczę Baculę. Jak już
sobie kupiłem tę nagrywarkę DVD do robienia backupów, to trzeba było w końcu
zacząć je robić. Niestety, pakiet z Baculą w PLD wciąż w rozsypce (ale się
buduje i nawet jakoś działa), a wsparcie dla DVD w Baculi wciąż nie domaga…
Ale jakoś udało mi się to zmusić do działania. Znaczy się, dysk mi rzęzi,
nagrywarka mruga diodą… czy z tej płytki się potem będzie dało coś odzyskać,
to się dopiero okaże.

Pythonowe frameworki…

(wpis z wczoraj)

Pierwszy Pythonowy framework dla aplikacji webowych jaki poznałem to był Zope 2. Potrzebne mi było coś takiego do
stworzenia interfejsu użytkownika dla naszego systemu zarządzania siecią. W PHP
babrać się nie miałem zamiaru, a robienie całości jako CGI to byłaby mordęga.
Padło na Zope’a, nic innego nie było, a przynajmniej nic na tyle popularnego,
żeby obiło mi się o uszy. Zope, z jednej strony potężna maszyna, z drugiej
wkurzające monstrum. W szczególności, że źle się za niego zabrałem. Wszystkie
szablony robiłem w DTML (bo wyczytałem w ZopeBook, że równie dobrze jak ZPT,
a dla programistów nawet lepsze), a cały kod rozwijałem through the web,
a więc to było bardziej skryptowanie a’la PHP, niż poważne tworzenie aplikacji.
W końcu przekonałem się do ZPT (bardzo porządny język szablonów, pozwalający
w miarę dobrze oddzielać logikę od prezentacji i utrudniający tworzenie
niepoprawnego XHTML), ale kod dalej rozwijany jest TTW, bo zmiana tego, to byłoby pisanie aplikacji (sporej już) od
zera.

Widząc słabości Zope zacząłem się rozglądać za alternatywami. Żeby
alternatywę poznać to trzeba spróbować, postanowiłem więc pobawić się czymś
innym. Po wstępnym rozpoznaniu tego co jest na rynku, postanowiłem spróbować od
CherryPy. Próba polegała na
przeportowania mojego generatora i przeglądarki statystyk dla Joggera (ta
czerwona kropa poniżej) na ten framework. Wcześniej to było zrealizowane
w postaci skryptów CGI z prymitywnymi printami. Zrezygnowałem
z języka szablonów wbudowanego w CherryPy, bo znając ZPT nie chciałem się
babrać w czymś nie opartym o XML (nie pilnującym składni generowanego kodu),
użyłem więc SimpleTAL. Sportowałem tak dużą część tego generatora statystyk,
z błędami i dałem sobie spokój (zająłem się innymi rzeczami). CherryPy na
początku zrobiło niezłe wrażenie jak prosto się w tym aplikację WWW
buduje
, a potem okazało się raczej prymitywne. Architektura CherryPy wręcz
wymuszała bałagan, zamiast porządkować kod (to IMHO jedna z funkcji
frameworków) — na dłuższą metę reprezentacja hierarchii URL poprzez
atrybuty obiektów to niezbyt dobry pomysł. Do tego stan aplikacji (aktualne
żądanie, odpowiedź, etc.) trzymany w zmiennej globalnej (i dostępny przez tę
zmienną)… wiem że to działa, ale wydaje się niezbyt eleganckie. Krótko mówiąc
CherryPy mnie nie zachwycił.

Kolejny był Nevow, oparty o Twisteda. Od początku wydawał się
bardziej skomplikowany niż CherryPy. Ale po doświadczeniach z prostotą
(prymitywizmem) CherryPy to mnie nie zrażało. Nevow intensywnie korzysta
z interfejsów i adapterów (jak się później okazało, zapożyczonych od Zope3), ma
własny, ciekawy język szablonów — oparty o XML i jeszcze bardziej niż ZPT
oddzielający prezentację od logiki (w szablonach nie ma nawet pętli).
Portowanie prostego CGI do Nevowa to była droga przez mękę, bo trzeba było się
nauczyć nowego, skomplikowanego narzędzia. Niektóre rzeczy w tym frameworku
okazywały się ostatecznie proste i logiczne, przy innych trzeba było się
nakombinować. Doprowadziłem conieco (prezentację listy wejść) do działania, ale
nie rozwiązałem wszystkich problemów i walka z Nevow mi się znudziła.
Ostateczne wrażenie raczej pozytywne, chociaż miejscami było pod górkę.
Doceniłem też wsparcie na IRCu.

Jakiś czas temu na grupie pl.comp.lang.python przeczytałem
sporo dobrego o Zope3. Wtedy to było
jeszcze eksperymentalne Zope-X3. Framework przepisany od zera, docelowo mający
zapewniać częściową kompatybilność wstecz (czy raczej wsparcie dla portowania
starych aplikacji) z Zope2. Co do tego że Zope należało przepisać od zera, nie
miałem wątpliwości. W to, że w Zope krył się potencjał też. Więc, gdy pojawiły
się release candidate Zope 3.1, postanowiłem spróbować.
Poczytałem dokumentację, zacząłem łapać o co w tych interfejsach i adapterach
(dużo intensywniej używanych niż w Nevow) chodzi i zabrałem się za portowanie
statystyk. Znowu początki były ciężkie, ale prawie na każdy problem Zope
oferował jakieś fajne rozwiązanie. Wszystko w postaci przejrzystego obiektowego
podejścia. W przeciwieństwie do takiego CherryPy Zope3 zachęca do porządku
i przemyślenia co jest obiektem, co jego prezentacją. Daje potężne mechanizmy
kontroli dostępu, bezpieczeństwa kodu, i18n, skórkowania, tworzenia i walidacji
formularzy i wielu innych rzeczy które w aplikacji są potrzebne. Jest to
architektura i zestaw narzędzi, czyli to czym framework powinien być. I się
sprawdza. Dzisiaj skończyłem portowanie statystyk i efekt jest lepszy niż
oryginał, a ewentualny dalszy rozwój będzie banalnie prosty (prostszy niż
w przypadku CGI).

Już po rozpoczęciu swojej zabawy z Zope3 stwierdziłem, że warto to
zastosować w firmie zamiast Zope2. Większość systemu (interfejs administratora,
serwisu, BOKu) zostanie na starym Zope’ie, bo przepisanie tego to znowu byłoby
wiele miesięcy, ale już interfejs użytkownika końcowego robię na Zope3. Tego
jest niewiele i i tak muszę to przepisać od zera. Obie części komunikują się
przez bazę danych i chodzą na różnych maszynach, więc zastosowanie dwóch
Zope’ów nie jest problemem. Mam nadzieję, że tej decyzji nie będę za jakiś czas
żałował, jak tego, że wpakowałem się z Zope2 i aplikację rozwijaną
TTW. No i to, że w ogóle wpakowałem się w kodowanie zamiast
adminowania…

Jest jeszcze wiele innych frameworków i, do tego, ciągle powstają nowe.
Części w ogóle nie znam, o części poczytałem w sieci i zrezygnowałem, bo ich
założenia mi nie pasowały. Niektóry zdawały się zbytnio iść w kierunku PHP,
którego przecież celowo unikam, inne miały jakąś dziwną architekturę, np.
Webware składające się z iluś komponentów, w których nie udało mi się ujrzeć
spójnej całości. Ciekawe co wygra — na świecie i wśród moich narzędzi.

Upgrade

Wczoraj ejabberd zaczął mi
szaleć. Nic z serwera nie przychodziło, to co się pisało szło efektywnie do
/dev/null, a nowe połączenia były odrzucane. Po restarcie zaczęło
działać, ale po godzinie znowu się zepsuło, tak samo.

Na serwerze miałem zainstalowanego dość starego Erlanga
(R9C-2) jak i samego ejabberd (0.7.5). Skoro działało, to po
co zmieniać. Jednak, gdy zaczęły się problemy, to aż głupio byłoby szukać
supportu do takich wykopalisk. Postanowiłem więc zrobić upgrade, ale bałem się.
Skok o kilka wersji przecież nie może przejść bezboleśnie.

Wczoraj wieczorem przygotowałem paczki PLD z najnowszym
Erlangiem i ejabberd. Poszło gładko, tylko
jeden mały patch był potrzebny. Ostatnim razem gdy próbowałem było gorzej,
w szczególności wychodziły jakieś problemy na AMD64. Dzisiaj postanowiłem te
nowe paczki zainstalować na serwerze. Przy okazji postanowiłem wypróbować
opcję --repackage RPMa, żeby mieć do czego wrócić, jak coś
pójdzie nie tak.

[root@serwus RPMS]# /etc/rc.d/init.d/ejabberd stop
Stopping ejabberd service..........................................[ DONE ]
[root@serwus RPMS]# rpm --repackage -Uvh erlang-R10B_7-0.1.amd64.rpm ejabberd-0.9.8-1.amd64.rpm
Preparing...                ########################################### [100%]
Repackaging...
   1:erlang                 ########################################### [ 50%]
   2:ejabberd               ########################################### [100%]
Upgrading...
   1:erlang                 ########################################### [ 50%]
   2:ejabberd               warning: /etc/jabber/ejabberd.cfg created as /etc/jabber/ejabberd.cfg.rpmnew
########################################### [100%]
Updating component authentication secret in ejabberd config file...
Generating erl authentication cookie...
Run "/etc/rc.d/init.d/ejabberd start" to start ejabberd server.
[root@serwus RPMS]# /etc/rc.d/init.d/ejabberd start
Starting ejabberd service..........................................[ DONE ]

Niemożliwe. To nie mogło być takie proste. A jednak, wygląda na to, że działa. Hmmm…

Firefox 1.0.7? Tylko dla wybranych?

I znowu pojawiła się nowa wersja Firefoksa, z krytycznymi poprawkami
security. I znowu tylko w amerykańskiej wersji (chociaż podobno po
1.0.6 już więcej nie miało się tak zdarzać). Czyżby użytkownicy lokalizowanych
wersji nie byli zagrożeni? A może im się bezpieczeństwo nie należy? A może
wybór wersji innej niż American English to ma być świadomy kompromis lub
oznacza głupotę/naiwność użytkownika?

Wszystko wskazuje na to ostatnie. Niestety, nie łatwo tą błędną decyzję
poprawić. Już dwa razy próbowałem zmienić wersję językową i zawsze kończyło
się to niedziałającym profilem. Nie chcę tracić ustawień i zainstalowanych
rozszerzeń, więc pozostaje mi trzymanie się dziurawej wersji… A może jeszcze
raz zaryzykuję zmianę, tym razem robiąc backup profilu?

Na Operę się na razie nie przesiadam, bo co Open Source, to Open Source,
nawet w wydaniu Mozilli (zmieniaj co chcesz, ale nie będziemy ci tego
ułatwiać, a wydając nawet nie sugeruj, że to Firefox). Z drugiej strony…
i tak w tym Fx mam zamknięte pluginy i rozszerzenia… może więc jednak Opera?

Napsułem? Czy coś innego się spieprzyło?

Przenoszę pewne pliki z jednego serwera zleceniodawcy zza granicy, na drugi…

Na drugim:

root@server2:~# cd /katalog_docelowy/
root@server2:/katalog_docelowy# ls
jakies katalogi tu są

Czyli nic specjalnego. Pozostaję tam zalogowany. Tym czasem na pierwszym
zaczynam transfer:

server1 ~ # rsync -e 'ssh' -avr /katalog_zrodlowy/katalog_do_przeniesienia ip_drugiego:/katalog_docelowy/
katalog_do_przeniesienia/plik1
katalog_do_przeniesienia/podkatalog/plik2
....

Czyli rutynowa operacja. Lecą sobie tak te pliki, w pewnym momencie się
zatrzymują, raczej na czymś większym, więc wygląda na to, że wszystko ok.
Zaglądam więc na drugi serwer, jak to tam wygląda:

root@server2:/opt# ls
-bash: /bin/ls: No such file or directory

Ooops… Co się dzieje???

root@server2:/opt# cd
root@server2:~# ls
-bash: /bin/ls: No such file or directory
root@server2:~# echo *
*
root@server2:~# cd /opt
root@server2:/opt# echo *
*
root@server2:/opt# cd /
root@server2:/# echo *
*
root@server2:/# logout
Connection to server2 closed.
[jacek@nic jacek]$ ssh root@server2
ssh_exchange_identification: Connection closed by remote host

Czyli serwer jakby odparował, a ja nie wiem, czy to przypadkiem nie moja sprawka… 😦 Spociłem się.