przystajnik

Monthly Archives: Styczeń 2010

OpenOffice vs Compiz

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.

Firebird – cyfrowe rozdwojenie jaźni

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.

Debian przez USB

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ł.

Dziewczęta, kochajcie Linuksa

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 🙂

Twój 64bitowy plugin był niegrzeczny

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.

Translate »