.: przystajnik :.

Jak dobrze policzyć – to wychodzi po 100 bitów na gitarę (żart dla liczących binarnie). Innymi słowy – czy muzyka z lat świetności ośmiobitowych Atari XE/XL to relikt dla wapniejących trucheł? Okazuje się, że niekoniecznie. Wiele osób przywraca im (muzyczkom) blask dawnej chwały za pomocą arcyciekawych aranżacji. Znajomy mnie ostatnio nakręcił jednym takim klipem, a jak zacząłem przeszukiwać internet odnalazłem kilka innych perełek… A zresztą, posłuchajcie sami:

Inspirujące…

Słabo piśmienny jestem, to i edytor tekstu rzadko uruchamiam. Ale od małżonki otrzymałem domowe polecenie służbowe zrobić ‘coś’ z denerwującym efektem rwania się fontów podczas pisania w Open Office’ie. Co to jest ‘rwanie fontów’? A to:

Problem pojawiał się podczas wprowadzania tekstu, przejścia z linii do linii, przesuwania tekstu, itp. W zasadzie uniemożliwiał sensowną pracę, bo ciągłe naciskanie ctrl+shift+R to niewiele ma wspólnego z wygodą.

Na początku podejrzewałem najnowszą wersję OpenOffica 3.1.1. Ale ponieważ nie znalazłem w sieci potwierdzenia tego błędu, swoją nieufność przeniosłem na włączonego Compiza. Po wyłączeniu efektów pulpitu wszystko się uspokoiło. No i mamy winowajcę. Ale przecież nie wyłączę całkiem Compiza – żeby się koledzy z Windows 7 ze mnie naśmiewali?

Zatem – albo sterowniki Nvidii, albo jakoś specyficzna opcja w Compizie. Sterowniki posiadam najnowsze (195.30), dlatego zajrzałem w inne miejsce. I udało się.

Przepis jest następujący – jeżeli ktoś nie posiada, należy zainstalować compizconfig-settings-manager:

sudo apt-get install compizconfig-settings-manager

Udajemy się do ustawień System->Preferencje->Menedżer Ustawień CompizConfig. Po uruchomieniu konfiguratora kolejny krok to wybranie opcji Narzędzia->Obejścia problemów->Force synchronization between X and GLX. Gotowe.

Przypuszczam, że problemy występuje tylko przy użyciu zamkniętych sterowników Nvidii – sprawdzenia na sprzęcie i sterownikach ATI tudzież Intela możliwości nie mam.

Głupia sprawa.

Firebird wydaje się być całkiem sprawnie rozwijanym projektem, na dodatek o całkiem niezłej opinii, ale jak do tej pory nie miałem konieczności, czy to woli, korzystania z niego. Konieczność nadeszła wraz z dniem, gdy zapukali do mnie uśmiechnięci ludzie z ofertą nie do odrzucenia – ‘Pan nam zrobi serwer, co?’.

Serwer oprócz kilku standardowych funkcji ma posłużyć jako centralna przechowalnia baz danych dla pewnego programu. Dotychczas każdy z użytkowników uruchamiał na swoim komputerze serwer Firebirda i program się z nim łączył, tworzył bazę, itp. ‘Ich’ Windowsy posiadały serwer baz danych w wersji 2.0.4, nowo postawiony Debian Lenny w repozytoriach również posiada wersję 2.0.4, zatem niemal wymarzona sytuacja dla wyemigrowania baz z Windowsa (ze wszystkich komputerów) do Linuksa.

O naiwny amatorze. Zawiodły niemal wszystkiego metody. Skopiowanie plików *.fdb z Windowsa i wrzucenie ich na Linuksa, próba rozpoznania ich przez linuksowy serwer Firebirda? Nic z tego. Zrzucenie zawartości bazy do pliku, ‘wciągnięcie’ ich do bazy na centralce? Brak oprogramowania (niewiedza?). Światełko w tunelu pojawiło się po zainstalowaniu programu FlameRobin. Odczyt baz lokalnie, skopiowanie jej na serwer zdalny? Nie ma takiej możliwości. Przeciąganie, upuszczanie – to bez sensu.

Krok po kroku udało się rzeczonemu amatorowi dojść do tego, że należy na Windowsie wykonać backup wybranej bazy danych, następnie przy wykorzystaniu tej kopii na Linuksie stworzyć nową bazę i wczytać zawartość. Nie będę może rozpisywał się nad technikalami (te można odczytać na tej stronie). Jednak okazało się, że nieźle wyglądający program FlameRobin nie potrafi, bądź też nie może obejść wymagań bazy i nie da się takiej migracji kopii bezpieczeństwa na serwer wykonać z pliku zapisanego na lokalnym komputerze. Backup musi zostać przeniesiony na Linuksa i dopiero stamtąd przywracany do użytku.

Celem stało się stworzenie prostego narzędzia/procedury przenoszenia lokalnych baz na serwer. Prostego w sensie stopnia skomplikowania przystępnego dla zwykłej pani Uli, dla której wpisywanie ścieżek dostępu dla baz danych (specyfika Firebirda) to przeszkoda nie do pokonania. Gdyby nie ergonomia Windowsa XP, sprawa mogłaby być banalnie prosta – zgodnie z przyzwyczajeniami z Thunara, tworzę nową akcję ‘wyślij na serwer’ pod prawym przyciskiem myszy. Po wybraniu pliku z rozszerzeniem .fdb, akcja odpala skrypt który robi z lokalnej bazy kopię bezpieczeństwa, wysyła ją na linuksowy serwer, a ten zajmuje się resztą.

Z tego tego sprytnie uknutego planu mogłem wykorzystać tylko ostatnią jego część – ‘linuksowy serwer, a ten zajmuje się resztą’. Nie posiadam w słowniku kulturalnych obelg potrafiących opisać frustrację i niemoc przy próbie wykorzystania Windowsa XP do stworzenia akcji konwersji/wysłania. Zabrakło mi do tego sił, czasu i najpewniej wiedzy. Ale w końcu to stary system.

Koniec końców panie musiały się nauczyć odczytywać ściągę, w której opisałem sposób otworzenia bazy w FlameRobinie, zrobienia kopii bezpieczeństwa, wrzucenia jej przez otoczenie sieciowe do katalogu w Linuksie, który cyklicznie sprawdza ten katalog i pojawiające się tam bazy wdraża do Firebirda w wersji linuksowej.

Właśnie to tytułowe rozdwojenie jaźni najbardziej mnie zadziwiło. Serwer Firebirda w wersji windowsowej i linuksowej generuje dwa różne pliki bazy. Dlaczego, jaki w tym cel, zamysł, przesłanie? Chyba nigdy się nie dowiem.

Wstyd to przyznać, ale nigdy nie byłem w stanie docenić uroku instalacji systemu z pendrive’a. Przyczyna była prozaicznej natury – przeważnie nigdy nie miałem styczności z na tyle rozwiniętym technologicznie sprzętem, który by to umożliwiał. Jak do kustosza zapomnianego muzeum, trafiały do mnie komputery których wiek chwały przebrzmiał wraz ze zmianą nomenklatury z MHz na GHz. Niektóre z nich prężyły swe intelektualne, bitowe muskuły wobec faktu posiadania pamięci 1GB, inne dziarsko rzęziły napędem DVD, ale to były jednostkowe przypadki. Któż by miał śmiałość zapytać się tych weteranów o możliwość uruchomienia się z pendrive’a. To nie wypada.

Aż przybył On, nowy, lśniący, z dyskami 1TB, cichym wiatraczkiem, płytą główną pachnącą przepalaną nowością, oraz … kompletnym brakiem napędów DVD/CD. I co? Ano, instalacja przez USB trafiła pod strzechy.

Ponieważ komputer był przewidziany do poważnej służby, jego przeznaczeniem był Debian 5.0. Opisów, jak sprawić, by instalator Debiana uruchomił się przez USB, znajdziemy w sieci krocie. Jednak, w każdym istnieje jedno, niewielkie niedomówienie, które prostych ludzi (takich jak ja), stawia przed problemem decyzyjnym i logistycznym.

Dlatego przedstawię swój schemat stworzenia boot’owalnego pendrive’a z instalatorem Debiania. Będzie on zawierał obraz ‘netinstall’, czyli taki, który do pełnego zainstalowania wymaga internetu, bo stamtąd ściągnie sobie wymagane pakiety. Zaletą jest to, że instaluje on niezbędne minimum (system po postawieniu na dysku zajmuje 60 – 100MB) i możemy go rzeźbić wedle własnego uznania.

Do tego zadania będziemy potrzebowali specyficznie spreparowany obraz boot’ujący (przykłady poniżej dotyczą instalacji systemu w wersji 64bitowej – dla innych wersji znajdziemy je tutaj):

wget http://ftp.debian.org/debian/dists/stable/main/installer-amd64/current/images/hd-media/boot.img.gz

Potrzebny będzie także instalator (inne wersje tutaj):

wget http://cdimage.debian.org/debian-cd/5.0.3/amd64/iso-cd/debian-503-amd64-netinst.iso

Teraz musimy przygotować swój pendrive. Wpinamy go do portu, jeżeli mamy automatyczne montowanie, odmontowujemy napęd który się pojawił i wykonujemy następujące czynności za pomocą programu gparted:

- z menu programu wybieramy napęd pendrive (upewnij się, że to na pewno pendrive! Np. za pomocą polecenia fdisk -l),
- kasujemy z niego tablice partycji,
- tworzymy tablicę partycji,
- tworzymy jedną partycję fat32,
- ustawiamy jej flagę boot,
- wszelkie zmiany zatwierdzamy przyciskiem ‘zastosuj’

Na tak przygotowany napęd wrzucamy obraz boot.img.gz:

zcat boot.img.gz > /dev/sdX1

(sdX1 to nazwa twojego napędu pendrive, ‘1′ oznacza tę jedyną partycję którą utworzyliśmy).

Następnie montujemy spreparowany pendrive, oraz kopiujemy na niego obraz instalatora:


mount /dev/sdX1 /mnt
cp nazwa_obrazu_instalatora.iso /mnt
umount /dev/sdX1

I to już wszystko. Cud sztuki rzemieślniczej umieszczamy w porcie usb, restartujemy komputer, wybieramy USB jako napęd boot’ujący i cieszymy się pięknym w swej toporności instalatorem Debiana.

W czym powyższy wywód różni się od innych opisów w sieci? Temat przygotowania pendrive’a i nagrania obrazu potraktowałem ręcznie, nie zważając na to, że powinno wystarczyć samo zcat (…). U mnie dopiero powyższy sposób zadziałał.

Wędrując po sieci w poszukiwaniu wczorajszego dnia, napatoczył mi się na ekran monitor wykład nt. użyteczności komendy find w Linuksie.

Nie uwierzycie, obejrzałem od startu do stopu i nawet jeszcze raz. A to za sprawą, kto by się spodziewał, nerda, geeka, czy jak jeszcze nomenklatura przyjęła nazywać osobowy obeznane w ‘tematach’.

Na słowo ‘fachowiec od Linuksa’ większości przed oczyma jawi się obraz długowłosego luzaka, który z zarostem sprzed tygodnia, nagim torsem i w bokserkach, znudzonym głosem prawi mądrości do swojej web-kamery. Nieodzowny wokół niego jest chaos organizacyjny, jak też żyjące własnym życiem resztki pizzy.

Jakże miło jest być wyprowadzonym z obłędnego labiryntu etykiet i stereotypów.

Przypuszczam, że dzięki bogatej wideotece Nixie, niejeden wątpiący uwierzyłby na powrót w Linuksa

Po instalacji najnowszego Ubuntu 9.10 w wersji 64bitowej życie ponownie nabiera sensu i rumieńców. Developerzy Ubuntu od przynajmniej trzech wydań nie poprzestają na staraniach o formę użytkowników, którzy mogliby przy sprawnie działającym systemie popaść w inercję i stagnację. Oczywiście, nie są to starania ‘z grubej rury’, raczej drobne ‘niedomówienia’ pozostawione w systemie ot, od niechcenia. To przeczy postępowi? Grzeszycie zwątpieniem, w tym na pewno jest cel.

Na pierwszy ogień na moim świeżo postawiony Ubuntu 9.10 poszedł plugin Flash’a. W zamierzchłych czasach zamknięte oprogramowanie (np. pluginy Javy, Flasha) twardo stawało w poprzek naturalnemu rozwojowi w kierunku systemów 64bitowych. Należało używać ‘nakładek’, które uruchamiały rzeczone pluginy w środowisku 32bitowym. Lecz krzemowe kopyta postępu skruszyły tarcze, za którymi chowali się ostatni przeczący i w większości wszystkie programy mają już swoje wersje 64bitowe. Z takim buńczucznym przeświadczeniem postawiłem system.

I wszystko ładnie się udało, poza tym, że zauważyłem brak możliwości sterownia filmami na Youtube (i nie tylko) – nie działały przyciski, a przynajmniej robiły to wedle własnego niezgłębionego uznania. ‘No tak, coś nie tak z Flash’em, ludzie niedługo Marsa skolonizują, a tu dalej problemy na 64bitach’ – pomyślałem, ale wiedziony ciekawością zerknąłem co się dzieje w procesach.

A tam na pierwszym miejscu w zajętości procesora jak i pamięci, widniał tajemniczy gość zwany npviewier.bin. Pierwsze słyszę – mam wirusa?

Nie do końca, choć efekt działania tego programu był bardzo zbliżony do wirusa wykonującego wewnętrzny atak DoS na zasoby naszego komputera. Okazało się, że w repozytoriach Ubuntu 9.10 plugin obsługujący technologię Flash nadal jest domyślnie w wersji 32bitowej (repozytoria dla 64bitów?), a npviewier.bin ma za zadanie sprawiać wrażenie, że wszystko jest OK.

Zdegustowany takim pionierskim podejściem w dystrybucji mającej aspiracje do bycia wiodącą, przeprosiłem się z konsolą i…

Usunąłem flashplugin-nonfree i flashplugin-installer:


sudo apt-get remove --purge flashplugin-nonfree flashplugin-installer


Ściągnąłem wtyczkę Flash wersji 64bitowej (o dziwo, jest taka na stronie http://labs.adobe.com/downloads/flashplayer10_64bit.html):


wget http://download.macromedia.com/pub/labs/flashplayer10/libflashplayer-10.0.42.34.linux-x86_64.so.tar.gz


Następnie było już z górki – rozpakowałem, skopiowałem:


tar zxof libflashplayer-10.0.42.34.linux-x86_64.so.tar.gz
sudo mv libflashplayer.so /usr/lib/mozilla/plugins


Po ponownym uruchomieniu przeglądarki tajemniczy proces npviewier.bin zniknął, zaczęły działać przyciski na animacjach Flash. Jak za starych, dobrych czasów.

Przy obecnym dobrobycie chyba już nie ma oryginalnych życzeń.

Trzymajcie się zdrowo i wespół w zespół z rodziną. Wszyscy.

Ronnie James Dio nieszczęsnym zbiegiem okoliczności jest przeze mnie bezwiednie szufladkowany w miejsce po Ozzym w Black Sabbath. Wiem, narażę się fanom Dio, ale sam nie wiem czemu pierwsze co przychodzi mi na myśl, to właśnie ten epizod. A faktem pozostaje to, że Dio to fenomenalny wokalista z fantastycznym dorobkiem. Że wspomnę o dokonaniach Rainbow czy właśnie Dio (jako formacji).

W dyskografii Dio znajdziemy dość słabo ocenianą płytę Sacred Heart (1985). Nie jestem do końca przekonany co do tych ocen, bo sam album może nie na poziomie dwóch pierwszych (Holy Diver i The Last in Line), ale przynajmniej połowa nagrań jest tym, do czego przyzwyczaił nas Dio. Album ten jest wyjątkowy też przez fakt, iż jako gitarzysta gościł na nim po raz ostatni Vivian Campbell (Def Leppard, Whitesnake, Riverdogs).

Jak na nierówny album przystało, mamy perełki jak i wypełniacze. Do perełek na pewno można zaliczyć dwa pierwsze kawałki, bezbłędnie szybki i z soczystymi riffami King of Rock and Roll oraz tytułowe Sacred Heart – przepełnione specyficznym wokalem Dio i kolejny raz świetną pracą gitary. Tę dobrą passę przerywa następny utwór, Another Lie, który spowalnia tempo i stylistyką próbuje niepotrzebnie nawiązać do zupełnie innego grania. Teraz przychodzą lepsze momenty, bo przestrzeń wypełnia Rock and Roll Children, efektowną pracą gitary i przekonywującym wokalem i tekstem Ronniego. Następna nieco typowa balladka Hungry for Heaven nie powala niczym specjalnym, choć i nie wzbudza odruchu przeskoczenia dalej. Spowolniony Like the Beat of Heart umacnia w nas specyfikę głosu Dio i pozwala nacieszyć się po raz kolejny dobrą gitarą jak i specyficznym rytmem. Świetny ‘firmowy’ kawałek Just Another Day to solidne granie, okraszone szybkimi riffami – to jedna z najmocniejszych stron tej płyty. Fallen Angels to lekko naciągany wypełniacz, może nie przepełnia obrzydzeniem, ale odstaje od poprzednich pozycji. Album zamyka Shot Shot, też nie przekonywujący, a przynajmniej nie po tym, co można było usłyszeć na początku.

Jak zatem widać, album nie jest majstersztykiem. Ale przynajmniej cztery kawałki (King of …, Sacred Heart, Rock and …, Another Lie) prezentują wysoki poziom i przynajmniej dla nich warto tę płytę posiadać na półce. Nadal będę jednak polecał przede wszystkim dwie pierwsze płyty Dio.

Co po ciężkim dniu przywróci nam błogi uśmiech i rumieńce na szarą twarz? Upuszczenie paru bitów z wrażych procesów, personifikujących całe zepsucie tego świata…

Kill, kill…

Kill to narzędzie o prostej budowie. Przesyła do kernela prośbę o unicestwienie wybranego procesu (SIGKILL). Potrafi też prosić o inne rzeczy (SIGTERM – poprawne zamknięcie, SIGSTOP – zatrzymanie procesu, itp), ale ponieważ jesteśmy na wojnie, będziemy procesy zabijać. Stąd SIGKILL. Destrukcji procesu można dokonać na dwa sposoby:

kill -KILL numer_pid
kill -9 numer_pid

Skomplikowane? Być może. Rozkładając to na czynniki pierwsze, mamy – kill, nasze polecenie, -KILL lub -9 – sygnał żądania, numer_pid – numer procesu który chcemy puścić z dymem. O co chodzi z tymi sygnałami? Jest ich kilka (jak wspomniałem wcześniej), wszystkie można sobie sprawdzić wpisując kill -l – jako parametr polecenie można podawać ich nazwę lub numer. Numer PID też może brzmieć nijako, a jest to najzwyczajniej w świecie numerek przypisany do konkretnego programu – taka niby metka. Dlatego polecenie kill potrafi bezbłędnie ustrzelić ten proces o którym nam chodzi (numery procesów pokaże nam polecenie ps).

Nie czas na te numery, killall

Jeżeli jesteśmy mocno zaaferowani, numery procesów mogą się nam dwoić i troić przed oczyma. Dlatego też powstało polecenie killall, któremu wystarczy podać nazwę procesu, aby killall go dopadł:

killall -9 firefox-bin


Zasada podobna jak powyżej – podajemy numer lub nazwę sygnału (nadal interesuje nas tylko 9, czyli SIGKILL). Niestety, to narzędzie też ma denerwującą czasem przypadłość – nazwa procesu musi być dokładnie podana, dlatego nie wystarczy ‘firefox’ a ‘firefox-bin’. Nieporęcznie?

Piszę i znikasz, pkill

W mniej precyzyjnym szale zniszczenia zakrojonym na większą skalę to właśnie pkill jest tym, co dobrze mieć pod ręką. Polecenie to zabije wszystkie procesy, które w jakimś stopniu będą pasowały z nazwy do podanego przez nas parametru:

pkill firefox

Powyższe wytłucze do ostatniego wszystkie procesy zawierające w nazwie ‘firefox’. Aby upewnić się, w co trafi pkill, można wylistować kandydatów do odstrzału:

pgrep -l firefox

I ew. zmienić nieco kryteria. Kolejna przydatna rzecz narzędzia pkill (jak i killall) to parametr -u nazwa_użytkownika. Dzięki niemu tylko podany użytkownik zostanie ogołocony z posiadanych procesów o podanej nazwie:

pkill -u panjozek firefox

Tylko nudziarze używają konsoli, xkill

Powyższe krwawe żniwa odbywały się za pomocą konsoli tekstowej. To skuteczne, szybkie i precyzyjne narzędzie, nie ma co udawać, że Linux go nie posiada. Jednak zwieńczeniem radosnego wycinania procesów może być polecenie xkill, które w środowisku graficznym pozwoli nam wskazać kliknięciem okno nielubianego programu. A co dalej się z nim stanie, to już wiecie.

Wygodnie jest przypisać sobie to polecenie pod skrót klawiszowy (u mnie ctrl + delete).

Oczywiście temat zabijania procesów nie został wyczerpany, jak też opis tych poleceń nie zawiera wszystkich dostępnych w nich parametrów. Jednak, do codziennego szybkiego radzenia sobie w krytycznych sytuacjach, proste metody opisane powyżej będą jak znalazł.

“War has never been so much fun…”

Zbliżają się święta, a że będzie jeszcze gorzej, stąd ta tematyka najbliżej opisująca stan ducha, który udziela się podczas codziennego przeciskania się przez tłum prących donikąd ludzi.

Parę wpisów wstecz temu, udowadniałem sobie i Wam, jakim przełomem może się okazać przeglądarka Midori, która uzyskiwała w testach prędkościowych zupełnie przyzwoite wyniki. Wyniki w porównaniu do Firefoksa 3.5 były nawet świetne, przyrost prędkości rzędu 30% – 40%. Zupełna bomba, jak na amatorską przeglądarkę rozwijaną przez dość skromną liczbę developerów.

Ponieważ sytuacja na rynku przeglądarek dynamiczną jest, z ciekawości postanowiłem uzupełnić dane o Google Chrome Beta, które ostatnio pojawiło się dla Linuksa (w wersji oficjalnie ogłoszonej i anonsowanej na stronie Google). Dokonałem dodatkowych testów na laptopie z Ubuntu 9.04, za pomocą tych samych stron co poprzednio (SunSpider oraz JSBenchmark).

Dla pewności powtórzyłem testy dla pozostałych przeglądarek (nowszych wersji, bo Firefox to już 3.5.5 a Midori to 0.2.1), ale nie przyniosły zmian. Oczywiście powyłączane miałem wszelkie dodatki typu blokowanie reklam, itp. A wyniki…

Cóż mogę powiedzieć… Ja naprawdę lubię Firefoksa, ale liczby w benchmarkach go dewastują…

Nie wiem, czy to przypadłość Firefoksa tylko pod Linuksem, ale daje to bardzo do myślenia.

Jeżeli ‘coś’ się nie zmieni w Gecko, to możemy niedługo zastanawiać się, po co Firefox wspiął się tak wysoko na drabinkę, skoro z takim hukiem wylądował. Zasadniczo podchodzę do Google i ich polityki wobec danych użytkownika z dużą rezerwą. Ale jeżeli światła dziennego nie ujrzy jakaś afera w tym temacie z udziałem tej firmy, to wątpię, czy coś zatrzyma pochód ich produktów, a na pewno Google Chrome. Chyba, że Firefox zacznie w końcu mocniej prężyć muskuły.

AKTUALIZACJA

Wykonałem testy dla kolejnych przeglądarek i dodałem do zestawienia Firefoksa w wersji 3.6b4 i 3.7a1pre. Poprawiają ogólny wizerunek tej przeglądarki, choć do lidera nadal długa droga. Midori oparta na WebKit’cie jest już w zasięgu nowego Firefoksa.

Przepuściłem także przez maszynę testującą Operę 10.10. Niestety, wyniki są kompletnie nieadekwatne do zachowania tej przeglądarki. Strony wyświetlają i przełączają się w miarę sensownie, a wg. testów Opera stoi w miejscu i nie działa – JSBenchmark to 50 punktów (im więcej tym lepiej), SunSpider to 7450 ms (sic! Im mniej tym lepiej). Może znajdę jakiś tajny przełącznik w tej przeglądarce