Karol „Zal” Zalewski

Nareszcie czas wolny. Tak mi się przynajmniej wydaje.

Marta dosłownie przed chwilą uzyskała wyższe wykształcenie. Teraz jeszcze tylko dwa lata do uzyskania tytułu magistra, a kto wie, może i zdecyduje się na coś więcej. Ja tymczasem załapałem się na kolejny, tym razem 5 rok informatyki, a we wrześniu powalczę jeszcze o zarządzanie tak, aby bez zbędnych kosztów przejść na 4 z 6 semestrów i specjalizować się w SBE&M. Interesująca opcja, prawda?

Natomiast jeszcze dzisiaj czeka mnie wyprawa do Warszawy, gdzie spędzę najbliższe 3 miesiące. Z samej praktyki naukowej relacji zapewne nie będzie. Wygląda na to, iż udział w niej będzie się wiązać z podpisaniem papierów dot. zachowania stosownej dyskrecji. W planach mam również pojawienie się na konferencji JAVArsovia 2009, która odbywa się w najbliższą sobotę. Przy okazji pobytu w Warszawie może uda mi się zostać notariuszem Thawte.

Pod koniec listopada, m.in. dzięki Ad!vice, wybieram się z Martą i całą ekipą (pozdrowienia m.in. dla Psychola i Tediego) na koncert Rammsteina w katowickim Spodku. Mam nadzieję, że oprócz samej muzyki będzie można również liczyć na widowiskowy show.

Wpis z serii czysto informacyjnych, niezawierający żadnej wartości intelektualnej. Wstęp do dłuższego wypoczynku i nieobecności na Joggerze.

Makdaam w swoim komentarzu do jednego z moich wpisów wspomniał o istnieniu kart typu smartcard wspierających OpenPGP. Taka alternatywa dla kart wspierających X.509 oraz trzymania kluczy GPG na dysku twardym. Obecnie kartę taką (tj. OpenPGP Card) można zdobyć na dwa sposoby. Pierwszym z nich jest dołączenie do FSFE, co kosztuje 60 € i skutkuje m.in. otrzymaniem ładnej, zielonej karty. Na to mnie oczywiście nie stać. Drugim sposobem jest kupno karty poprzez sklep kernel concepts za jedyne 16,40 € plus koszty przesyłki. Do tego przydałby się jeszcze standardowy czytnik smartcard. We wspomnianym sklepie kosztuje przynajmniej 30 €, a podejrzewam, że w Polsce jest dostępny za nieco niższą kwotę. A jakie korzyści płyną z posiadania takiej karty?

To proste. Umożliwia bezpiecznie przechowywanie i wykorzystywanie prywatnego klucza OpenPGP bez obawy o to, iż zostanie on komukolwiek ujawniony (nawet w zaszyfrowanej postaci). Rozwiązanie takie ułatwia również wykorzystanie tego klucza na wielu komputerach - karta mieści się w portfelu, a czytnik posiada niewielkie rozmiary.

A jak już jesteśmy przy inteligentnych kartach to jestem ciekaw, jak szeroko wykorzystywane są Java Cards.

Odbiegając od tematu. Wyjeżdżając na praktykę mam w końcu okazję do tego, aby zostać notariuszem Thawte WoT (obok CAcert). Wygląda na to, że w firmie Ce3 (N 52°13′7.3164″, E 20°59′20.6016″) znajduje się sporo osób, które są w stanie nieodpłatnie poświadczyć tożsamość w programie Thawte. I nie jest to aż tak daleko od akademika w którym będę przebywać (okolice N 52°14′15.2118″, E 20°54′59.871″). To niesamowite, iż niektórzy "notariusze Thawte" oczekują ponad 100 złotych za potwierdzenie tożsamości, którego rezultatem jest 35 z 50 wymaganych punktów. To więcej, niż życzą sobie polskie centra certyfikacyjne.

Wstęp

Obecnie wiele narzędzi umożliwia szyfrowanie i podpisywanie danych z wykorzystaniem OpenPGP. Wystarczy wspomnieć o rozszerzeniu Thunderbirda o nazwie Enigmail, czy też o komunikatorze Psi (XMPP) umożliwiającym prowadzenie poufnych rozmów oraz podpisywania statusów. A co ze wsparciem dla OpenPGP ze strony Firefoksa?

Poniżej znajduje się prosty przepis na uzyskanie wspomnianej funkcjonalności w Firefoksie i przykład jej wykorzystania. Zapraszam do dalszej lektury.

FireGPG

FireGPG to darmowe rozszerzenie przeznaczone dla Firefoksa integrujące go z programem GPG dystrybuowane na licencji MPL. Dzięki niemu Firefox zyskuje możliwość szyfrowania, deszyfrowania i podpisywania danych wysyłanych i pobieranych ze stron. Do tego dochodzi możliwość łatwego importu oraz eksportu kluczy. Całość w całkiem przystępnej formie graficznej.

Co więcej, FireGPG integruje się z interfejsem webowym poczty dostarczanej przez Google (GMail oraz Google Apps), co znacząco ułatwia stosowanie podpisów i szyfrowania treści zawartej w mailach z wykorzystaniem GPG.

Wykorzystanie FireGPG na stronie WWW

Poniżej znajduje się przykładowa wiadomość podpisana z wykorzystaniem GPG i FireGPG.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Treść podpisana, czy też zaszyfrowana z wykorzystaniem GPG, a pośrednio z FireGPG, nie może stanowić zwyczajnego kodu (X)HTML. Wprowadzane przez przeglądarki modyfikacje naruszałyby zarówno treść, jak i sam podpis. Dlatego też podpisana przeze mnie treść, wraz z podpisem (clearsign) znajduje się między znacznikami <pre> oraz </pre>. Nie jest to idealne rozwiązanie, prawda?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

iEYEAREKAAYFAkpDkqUACgkQMQCjynuqQtcWqwCgnWvoaCzbdroSXnhVkId1HUnK
xYcAnjUJTugLETkb8Gl9sjUI3FIeaEoO
=IVd/
-----END PGP SIGNATURE-----

Osoby korzystające z innych przeglądarek, niż Firefox z rozszerzeniem FireGPG dostrzegą tutaj brzydki (subiektywne określenie) blok <pre>, a próba sprawdzenia podpisu z wykorzystaniem GPG i kodu źródłowego tego bloku zakończy się fiaskiem ze względu na obecność w nim encji. FireGPG wyświetli natomiast ładną ramkę z informacją o numerze klucza i jego właścicielu, o ile w keyringu znajduje się mój klucz publiczny (odcisk 0x7BAA42D7).

Ale to nie wszystko. Wiadomość nie tylko może być podpisana, ale również zaszyfrowana z wykorzystaniem klucza publicznego odbiorcy (precyzyjniej, zaszyfrowany zostanie klucz sesyjny), lub szyfrów blokowych (np. AES) umożliwiających szyfrowanie oraz deszyfrowanie z wykorzystaniem jednego i tego samego klucza. Oto przykład z wykorzystaniem symetrycznego szyfru blokowego, jakim jest popularny AES z 256 bitowym kluczem.

-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.6)

jA0ECQMCqXvkJcDSH99g0kMBR8GY1+W20MhBqxDVglqMbRb9lo64LgTWNZNrbd9u
RDmMC0fOr9pl5oqhnnkIklKUYWP0mWsIROclq/1++/XN2/ES
=WHBY
-----END PGP MESSAGE-----

Wykorzystano hasło blog.4zal.net.

Podsumowanie

Wygląda na to, iż wykorzystanie FireGPG w pewnym stopniu rozwiązuje problem nad którym niedawno rozmyślałem. Czy jest to rozwiązanie idealne? Oczywiście, że nie, ale możliwym jest, iż jest ono wystarczające. Polecam samodzielnie skorzystać z FireGPG w przypadku pracy z Firefoksem i samodzielnie ocenić funkcjonalność tego rozszerzenia. Polecam również zajrzeć do wpisów Piotra Koniecznego dot. wykorzystania GPG w systemie Windows.

Na samo zakończenie, tak z ciekawości, proste pytanie - czy korzystasz z GPG, a jeśli tak, to jak często i w jakim celu?

Wstęp

Już wiele razy wspominałem o możliwości szyfrowania dysków twardych z wykorzystaniem DM-Crypt oraz LUKS. Całość działa całkiem sprawnie zarówno pod Linuksem, jak i Windowsem (ten ostatni wymaga FreeOTFE), a do tego wiele dystrybucji Linuksa (m.in. Ubuntu) umożliwia utworzenie zaszyfrowanych partycji już podczas instalacji systemu. Po tej ostatniej operacji każda próba uruchomienia systemu zostanie poprzedzona prośbą o podanie hasła. I tutaj pojawia się pytanie.

A co gdyby tak zamiast mozolnego podawania hasła, wystarczyło podłączyć do komputera odpowiedni pendrive pełniący rolę sprzętowego klucza? Oto i rozwiązanie przeznaczone dla systemu Ubuntu 9.04 z zaszyfrowanym już dyskiem (DM-Crypt + LUKS)!

Przygotowanie klucza

Z powyższym problemem poradzimy sobie umieszczając na pamięci Flash plik będący kluczem umożliwiającym odszyfrowanie danych. Zacznijmy zatem od przygotowania dysku USB.

Na samym początku dzielimy dysk na partycje, lub tworzymy jedną dużą partycję przy pomocy programu cfdisk, lub fdisk. Jest to konieczne ze względu na sposób działania skryptu, który zostanie pokazany w późniejszej części wpisu. Następnie formatujemy wybraną partycję z wykorzystaniem systemu plików Ext2. Mój dysk USB ma obecnie oznaczenie /dev/sdb i na nim wykonuję wszystkie operacje.

sudo cfdisk /dev/sdb
sudo mkfs.ext2 /dev/sdb1

Co dalej? Przygotujmy klucz!

sudo mkdir /media/Crypto
sudo mount /dev/sdb1 /media/Crypto
sudo dd if=/dev/urandom of=/media/Crypto/klucz bs=512 count=4

Plik nie powinien być ukryty (np. poprzez dodanie "." na początku jego nazwy), ani zawierać liter spoza ASCII. Teraz wystarczy dodać obsługę naszego klucza do wcześniej zaszyfrowanej partycji. W moim przypadku mowa o partycji /dev/sda3. Poniżej znajduje się komenda, którą należy wykonać. Należy pamiętać, iż do jej wykonania są potrzebne nie tylko uprawnienia administratora, ale również jedno z haseł LUKS-a, które posłużyły do zaszyfrowania dysku twardego.

sudo cryptsetup luksAddKey /dev/sda3 /media/Crypto/klucz

I to właściwie koniec zabawy po stronie dysku USB. Możemy go odmontować i na jakiś czas schować w bezpiecznym miejscu.

Przygotowanie systemu operacyjnego

Problem z Ubuntu polega na tym, iż twórcy dystrybucji dostarczają jedynie skrypt niezbędny do deszyfrowania dysków przy pomocy hasła podanego przez użytkownika. My zaś chcemy uzyskać możliwość automatycznego pobrania pliku z hasłem z dysku USB, a w przypadku jego braku - podać je ręcznie. W tym celu wykorzystamy skrypt stworzony przez Wejna.

Nim to jednak nastąpi - ostrzegam! Zmiany, które teraz wprowadzamy mają istotny wpływ na sposób funkcjonowania systemu operacyjnego. Błędy w ich wprowadzaniu mogą doprowadzić nie tylko do problemów z jego uruchomieniem, ale również do zniszczenia danych na dysku! Wszystko, co tutaj zawarłem zostało przeze mnie przetestowane i funkcjonuje w moim systemie. Nie oznacza to jednak, iż biorę odpowiedzialność za straty spowodowane poniższym opisem. Wybrany system plików, stworzenie partycji na dysku USB, czy też nawet nazwa pliku mają znaczenie. I to duże, o czym sam się przekonałem w ciągu kilku godzin zabawy z tym rozwiązaniem.

cd /usr/local/sbin
sudo wget http://blog.4zal.net/files/beckman-crypto-usb-key.sh
sudo mv beckman-crypto-usb-key.sh keyscript
sudo chmod 755 keyscript

Skrypt ten jest o tyle interesujący, iż sam wykrywa podłączone do komputera dyski USB w trakcie uruchamiania systemu operacyjnego, a następnie usiłuje pobrać z nich plik z kluczem o podanej przez użytkownika nazwie. Jego nazwę określa się poprzez edycję pliku /etc/crypttab. Poniżej widać poprawną zawartość tego pliku tekstowego. "Klucz" oznacza nazwę pliku z kluczem (normalnie znajduje się tam wartość "none"), a dodatkowy atrybut "keyscript" pokazuje lokalizację ww. skryptu.

# [target name] [source device] [key file] [options]
sda3_crypt /dev/disk/by-uuid/54f....-751a3a4f239a klucz luks,keyscript=/usr/local/sbin/keyscript

Jesteśmy już prawie na końcu. Należy teraz jeszcze dodać do pliku /etc/initramfs-tools/modules informację o jednym module, który będziemy chcieli załadować jeszcze przed uzyskaniem dostępu do głównego systemu plików. Jest on odpowiedzialny za obsługę dysków USB.

usb_storage

Po wykonaniu wszystkich powyższych czynności czas na stworzenie nowego pliku initrd.img odpowiedzialnego za tworzenie podczas bootowania systemu pierwotnego, najprostszego środowiska w którym funkcjonuje jądro. Należy pamiętać, iż błędy w ww. skrypcie, czy też w pliku crypttab mogą w znaczący sposób uniemożliwić nam dostęp do naszych danych, a w skrajnych przypadkach nawet je zniszczyć. Przed wykonaniem poniższego polecenia zalecam zrobienie kopi zapasowej obecnego pliku initrd.img z folderu /boot, gdyż zostanie on nadpisany. Co ważniejsze - warto przygotować GRUB-a do wykorzystania jego starej wersji na wypadek porażki przy uruchamianiu systemu przy obecności nowej wersji tego pliku.

sudo update-initramfs -u ALL

Po ponownym uruchomieniu system powinien samodzielnie przeszukać podłączone dyski USB pod kątem opisanego pliku z kluczem, a w przypadku jego nieodnalezienia - poprosi o podanie hasła przez użytkownika.

Należy pamiętać, iż wprowadzone w ten sposób ustawienia są stałe i nie znikną wraz z aktualizacją jądra systemu Linux z tego względu, iż initrd.img, w którym znajdują się wprowadzone zmiany, jest generowany na komputerze użytkownika nawet przy aktualizacji kernela.

Podsumowanie

Jeżeli wszystko poszło po naszej myśli, od teraz system możemy uruchamiać tradycyjnie, podając hasło przy starcie, lub podłączając na czas startu pendrive zawierającego klucz umożliwiający dostęp do dysku. LUKS obsługuje bodajże do ośmiu różnych kluczy przypadających na jeden zaszyfrowany wolumen.

Mam nadzieję, iż opis ten okaże się przydatny i zachęci Was do samodzielnych eksperymentów. Nic nie stoi przecież na przeszkodzie, aby wspomniany skrypt pobierał dane tylko i wyłącznie z jednego, konkretnego dysku USB (korzystając z informacji o jego numerze seryjnym, czy też UUID), co mogłoby stanowić dodatkowe utrudnienie przy próbie dostępu do komputera. Powodzenia!

Wstęp

Chyba nikt obecnie nie wyobraża sobie uzyskania dostępu do osobistego konta bankowego poprzez Internet bez wykorzystania protokołu HTTPS (nie tylko szyfrowanie, ale też dowód autentyczności). Z pocztą elektroniczną (S/MIME), dokumentami (np. ODF, PDF itd.) oraz programami (np. podpisane javowe JAR-y) jest już nieco inaczej, ale hierarchiczna PKI i standard X.509, wraz ze wzrostem świadomości użytkowników oraz tworzeniem nowych regulacji prawnych, powoli zyskują na znaczeniu. Po drugiej stronie znajduje się rozwiązanie bardzo podobne, ale w przeciwieństwie do PKI, zdecentralizowane - Web of Trust (ang. sieć zaufania) z wykorzystaniem m.in. standardu OpenPGP. Oczywiście, na bazie PKI można stworzyć zdecentralizowany system (patrz CAcert) i odwrotnie, ale nie jest to istotą tego, o czym chcę napisać.

To, co mnie interesuje to możliwość wykorzystania podpisu elektronicznego przy tworzeniu współczesnych serwisów internetowych opartych na treści dostarczanej przez samych użytkowników.

Dlaczego nie HTTPS?

Podpis elektroniczny i strony internetowe to nie jest coś, co dobrze ze sobą współgra. HTTPS pozwala, z wykorzystaniem kwalifikowanych certyfikatów, na określenie autentyczności wyświetlanej strony. Rozwiązanie to ma jednak szereg wad, które ujawniają się w momencie, gdy nie zależy nam na szyfrowaniu danych, lecz jedynie na ich podpisie. Przykładem mogą być blogi, czy też fora (HTML/XHTML) i próba złożenia podpisu elektronicznego przez autora pod napisanym przez siebie wpisem. Jakie wady posiada HTTPS w takiej sytuacji? Na przykład:

• wymaga dostępu do konfiguracji serwera WWW,
• wymaga umieszczenia klucza prywatnego po stronie serwera,
• nie posiada możliwości określenia tego, które dane zostały wygenerowane przez serwer, a które przez użytkowników (np. nie można podpisać się jedynie pod wpisem na blogu, a pominąć cudze komentarze),
• nie pozwala na określenie kilku autorów przesłanego tekstu (np. w przypadku agregatora treści),
• itp.

Oczywistym jest, iż HTTPS został zaprojektowany zupełnie do innych celów, niż te o których obecnie myślę. Potrzebne jest zatem inne rozwiązanie powyższego problemu.

Sugerowane rozwiązanie

W celu rozwiązania problemu należałoby określić w jaki sposób można byłoby dodać do kodu w (X)HTML-u podpis elektroniczny zapisany w formie ASCII (np. kodowanie Base64) i w jaki sposób powiązać go bezpośrednio z daną gałęzią w kodzie (X)HTML. Warto byłoby, aby istniało wsparcie zarówno dla OpenPGP, jak i dla X.509.

Sądzę, iż dałoby się to zrobić na co najmniej trzy sposoby. Jednym z nich byłoby rozwinięcie standardu (X)HTML o nowe znaczniki związane bezpośrednio z podpisem elektronicznym. Drugi sposób polegałby na wykorzystaniu istniejących znaczników (X)HTML oraz RDF/RDFa w celu dodania do dokumentów odpowiednich metadanych umożliwiających maszynowe sprawdzanie poprawności podpisów. Trzeci sprowadzałby się do stworzenia odpowiedniego mikroformatu.

Od razu nasuwają się pytania dot. tego, pod czym należałoby się podpisywać. Czy tylko i wyłącznie pod kodem (X)HTML, a może również brać pod uwagę zawartość obiektów zewnętrznych? W pierwszym przypadku możliwa byłaby sytuacja w której to uległaby zmianie zawartość dodanego obrazka, lecz nie jego adres - podpis nadal byłby prawidłowy, a "treść" uległaby zmianie. I co z CSS-em, JavaScriptem itp.? Gdzie należałoby postawić granicę?

Forma zapisu takich danych to tylko część problemu, równie ważna byłaby ich obsługa przez przeglądarki WWW. Zapewne nie byłby to szczególnie kłopotliwe w przypadku wykorzystania standardu X.509 (przeglądarki posiadają już część koniecznych narzędzi). Nieco trudniej byłoby z OpenPGP. Jednak to, co najważniejsze w Internecie mogłoby stanowić największą barierę dla wdrożenia tego rozwiązania. Człowiek. Jak przeglądarka miałaby wskazać odbiorcy, iż tylko część treści na stronie jest prawidłowo podpisana? Jak można byłoby uchronić użytkownika przed złudzeniem autentyczności strony, gdyby stanowiła jedynie zlepek danych (artykułów, zdań, czy też nawet pojedynczych wyrazów i liter) z innych, podpisanych cyfrowo źródeł? Sporo pytań, a o satysfakcjonujące odpowiedzi trudno.

Jestem ciekaw, czy istniałoby również zapotrzebowanie na takie rozwiązanie. Nie na szyfrowanie danych wymienianych między użytkownikiem, a serwerem, lecz na możliwość łatwego sprawdzenia, kto się pod danym tekstem podpisał. Osiągnięcie autentyczności zapewnianej nie przez login wykorzystywany w danym serwisie, czy też poprzez OpenID, a poprzez np. Centrum Certyfikacji, co byłoby jeszcze bardziej uniwersalnym rozwiązaniem.

Oczywiście, to tylko zarys pomysłu. Mniej, czy bardziej błędny. Wszelkie komentarze są mile widziane (POK).

PS. Przy okazji przeglądam XEP-y i znalazłem kilka związanych z szyfrowaniem, które mi się spodobały: XEP-0027 (OpenPGP, implementacja w Psi), XEP-0102 (PKI) oraz XEP-0188 (ala Off-the-record w Pidgina). I coś z innej beczki - XEP-0237, mój telefon błaga o implementację tego.

Wstęp

Pisałem niedawno o możliwości zamiany telefonu z wewnętrznym GPS-em w zewnętrzny moduł z interfejsem Bluetooth (np. ExtGPS, J2ME GPSd, czy też GPSd4SE) i wykorzystaniu go np. z TangoGPS oraz darmowymi mapami z projektu OpenStreetMap. Teraz czas na opis tego, jak sobie poradzić, gdy chcielibyśmy skorzystać z telefonu i GPS-a w roli interaktywnej mapy.

TrekBuddy

TrekBuddy ta aplikacja napisana w J2ME przeznaczona na telefony komórkowe, a służąca do obsługi GPS-u. Współpracuje zarówno z wewnętrznymi, komórkowymi GPS-ami, jaki tymi zewnętrznymi. Posiada naprawdę bogate możliwości. M.in. elektroniczny kompas, obsługę atlasów, nanoszenie i zarządzanie POI oraz tras, wsparcie dla zewnętrznych i wewnętrznych GPS-ów oraz logowanie odczytów do plików w formatach GPX/NMEA. Wszystko to oczywiście za darmo. Szkoda tylko, że nie posiada otwartego kodu źródłowego.

Warto jedynie wspomnieć, iż osoby chcące skorzystać z logowania, a posiadające GPS wbudowany w komórkę powinny uważać na logowanie w formacie NMEA. W przypadku niektórych telefonów (np. Sony Ericsson) tak wygenerowane dane będą niekompletne np. nie będą zawierać informacji o szerokości i długości geograficznej. Zaleca się zatem stosowanie formatu GPX. Konwersja formatu GPX do innych jest stosunkowo prosta i możliwa z wykorzystaniem m.in. programu GPSBabel. Same pliki z logami można znaleźć na karcie pamięci telefonu w folderach TrekBuddy/tracks-gpx oraz TrekBuddy/tracks-gpx.

Mapy

Sam TrekBuddy i GPS do niczego nam się nie przydadzą. Określenie szerokości, czy też długości geograficznej daje nam niewiele bez dostępu do mapy. Jak zatem zdobyć darmową i w pełni legalną mapę terenu?

Wystarczy skorzystać z programu napisanego w Javie i udostępnianego na licencji GPL. Mowa o TrekBuddy Atlas Creator. Dzięki niemu jesteśmy w stanie w prosty sposób określić teren, którego atlas chcemy stworzyć, a on sam pobierze odpowiednie zdjęcia z wybranego źródła (m.in. Google Maps, czy też OpenStreetMap) i stworzy dane dla TrekBuddy. Jak pewnie zauważyliście, wspomniałem o atlasie, a nie o mapie. Dlaczego? Atlas jest to zbiór map różnego typu i o różnej skali. W przypadku TrekBuddy atlas zawiera warstwy, a one zaś zawierają mapy. Warstwa jest odpowiedzialna za skalę, a mapy to np. mapa satelitarna, czy też topograficzna.

Mapy zajmują nieco miejsca, szczególnie te z wieloma wielkoskalowymi (szczegółowymi) warstwami. Warto zatem przygotować sobie jeden atlas na dany kraj np. Polski z warstwami od 0 do 12 z Google Maps (zajmujący około 150 MiB) oraz kilka innych, bardziej szczegółowych dla konkretnych miast. Tak wygenerowane mapy należy następnie przenieść na kartę pamięci telefonu np. do folderu TrekBuddy/maps.

Points of interest

Mapy to jedna rzecz. Drugą, równie ważną, są tzw. POI będące punktami zainteresowań, czy też użyteczności publicznej określającymi położenie np. aptek, restauracji, stacji benzynowych itp. Mapy nie posiadające stosownych POI są raczej mało przydatne w przypadku turystycznych zastosowań. Jak zatem zdobyć te dane? Czy będą pasować do naszych darmowych map i TrekBuddy?

Wspomniane punkty składają się z nazwy, opisu i położenia geograficznego. Oznacza to, iż dobrze przygotowane punkty powinny pasować do każdej dobrze skalibrowanej mapy. Zaś w celu pozyskania zbioru POI można skorzystać z darmowych baz rozwijanych przez społeczność użytkowników. Mowa m.in. o PoiPoint.pl, czy też tej dostępnej na forum TrekBuddy.

Same zbiory punktów są odczytywane przez TrekBuddy w formacie GPX. Oznacza to, iż pliki z POI należy skopiować do folderu TrekBuddy/wpts na karcie pamięci telefonu. Podczas korzystania z atlasu, czy też mapy można je wyświetlać w zależności od aktualnych potrzeb. TrekBuddy umożliwia sortowanie takich punktów po nazwie, opisie, czy też odległości od naszego obecnego położenia na mapie. Nic też nie stoi na przeszkodzie, aby dodawać własne POI, w tym celu TrekBuddy stworzy osobny plik GPX we wspomnianym folderze.

Podsumowanie

Tak opisane rozwiązanie nie jest, co prawda idealne i należy mieć to na uwadze podczas podróży, ale z pewnością jest bardzo pomocne. Szczególnie, gdy nie ponosimy kosztów podczas korzystania z nich. Istnieją również komercyjne mapy dla TrekBuddy dostępne wraz ze zbiorami POI, ale ich opis nie był moim celem. Mam nadzieję, że podane przeze mnie informacje okażą się przydatne dla osób zainteresowanych wykorzystaniem GPS-ów w codziennym życiu.

Sama obsługa TrekBuddy nie powinna nikomu nastręczyć problemów. Całość jest stosunkowo dobrze opisana i nie widzę potrzeby opisywania tego. Znacznie ciekawszy jest natomiast temat tworzenia dobrych map, włącznie z uczestnictwem w projekcie OpenStreetMap, czy też zabawa w tzw. geocaching. Ale o tym nieco później, jak już lepiej poczuję się w temacie amatorskiej kartografii.

Gdyby ktoś miał ochotę podpiąć pod tangoGPS mapy z Google Maps to polecam skorzystać z poniższych adresów, które należy podać w konfiguracji TangoGPS:

http://mt1.google.com/mt/v=w2.92&hl=pl&z=%d&x=%d&y=%d&s=Galileo
http://khm1.google.com/kh/v=40&hl=pl&z=%d&x=%d&y=%d&s=Galileo
http://mt1.google.com/mt/v=w2p.87&hl=pl&z=%d&x=%d&y=%d&s=Galileo

Są to kolejno: mapa ulic, mapa satelitarna oraz mapa topograficzna. Wygląda na to, iż na daną chwilę sprawdzają się doskonale.

Niedawno wspominałem o możliwości udostępnienia na zewnątrz, poprzez interfejs Bluetooth i Internet, wewnętrznych GPS-ów montowanych w komórkach. Całość z wykorzystaniem standardowego protokołu NMEA 0183 rozumianego przez wiele urządzeń i programów. Narzekałem również na implementację JSR-179 w telefonach Sony Ericsson, która uniemożliwiała wykorzystanie standardowych aplikacji (np. ExtGPS oraz J2ME GPSd) przeznaczonych do tego celu. Postanowiłem zatem wziąć sprawy w swoje ręce i tak powstał javowy MIDlet o nazwie GPSd4SE, czyli "GPSd for Sony Ericsson phones".

Nawiązałem kontakt z autorami J2ME GPSd (Andrea Bittau, Tomáš Janoušek), poprosiłem o możliwość wykorzystania kodu i wydania go na licencji BSD. Co prawda J2ME GPSd to projekt Open Source, ale jego licencja była do tej pory nieokreślona. Tak, czy inaczej pobawiłem się nieco z Javą i stworzyłem bardzo prosty konwerter danych dot. współrzędnych do kodu NMEA (obecnie wpisy typu RMC).

Zapraszam do ściągnięcia gotowego JAR-a z wersją 0.1, lub źródeł z repozytorium Mercuriala i samodzielnej kompilacji z wykorzystaniem programu Ant (wymaga Java JDK).

hg clone http://hg.assembla.com/GPSd4SE
cd GPSd4SE
ant

Program ten przetestowałem na telefonie Sony Ericsson C702. Umożliwia on przekazywanie danych NMEA z informacjami o położeniu modułu (szerokości i długości geograficznej) oraz danych dot. położenia wykrytych satelitów wielu odbiorcom - zarówno za pośrednictwem interfejsu Bluetooth, jak też i Internetu. Domyślnie próbuje wykorzystać A-GPS, więc pierwsze określenie pozycji jest bardzo szybkie. Instrukcja obsługi znajduje się na mojej stronie oraz na stronie projektu J2ME GPSd. Sama konstrukcja programu jest bardzo prosta - z jednej strony GPSd4SE pobiera dane z wewnętrznego GPS-u telefonu, a z drugiej tworzy m.in usługę Bluetooth udostępniającą dane w formacie NMEA, dzięki czemu takie programy, jak np. xgps, czy też tangogps są w stanie poprawnie funkcjonować. Oto przykładowe dane wygenerowane przez GPSd4SE.

$GPGSV,3,1,10,28,66,121,,15,57,289,33,08,49,075,,10,26,208,*7F
$GPGSV,3,2,10,27,26,264,,19,13,030,,07,11,080,,18,11,328,34*79
$GPGSV,3,3,10,17,06,141,,26,05,305,*7B
$GPRMC,122930,A,5423.03086,N,01837.17181,E,000.0,000.0,220609,000.0,W*6E

W przyszłości mam zamiar dodać możliwość przesyłania nieco bardziej skomplikowanych danych (np. dotyczących wysokości na której znajduje się telefon) oraz prostego klienta DynDNS. To ostatnie jest szczególnie interesujące - podłączyć komórkę do zewnętrznego zasilania, włączyć GPSd4SE z opcją internetową i ustawić domenę, która będzie na niego wskazywać. Wystarczy teraz pobrać dane łącząc się np. z gps.4zal.net:666 i mamy informację dot. tego, gdzie znajduje się np. samochód. Oczywiście, wątpię, aby komórka nadawała się do tego typu celów, ale gadżet byłby z tego miły.

W przypadku uwag, co do poprawności działania programu, czy też stylu, w jakim został napisany (brak komentarzy sam dostrzegam), proszę o kontakt. Gorąco również zachęcam do samodzielnej modyfikacji kodu!

PS. A jak ktoś nie ma ochoty korzystać z komórki, jako zewn. GPS-u to polecam wykorzystać TrekBuddy.

Wstęp

Tytułowy palmtop jest stary, jak świat. Ma już na karku ponad 7 lat i pracuje pod kontrolą nieco tylko młodszego od niego Windowsa Mobile 2003. Jakiś czas temu, już po instalacji dystrybucji Linuksa o nazwie Familiar, kompletnie straciłem zainteresowanie nim. Aż do chwili obecnej.

Hardware

Podejrzewałem go o problemy z czytnikiem kart SDIO oraz z nadajnikiem Bluetooth. Okazuje się jednak, że problemy z czytnikiem kart wynikały z tego, iż obsługuje jedynie karty SD niektórych producentów o pojemności mniejszej od 1 GiB. Tak przynajmniej z doświadczeń wynika. A BT? Działa wolno (wersja 1.1), ale całkiem stabilnie. O ile ktoś nie zechce skorzystać z szyfrowanego połączenia, lub z możliwości przeglądania plików na palmtopie. OBEX Push to jedna z nielicznych dozwolonych opcji. Nawet całkiem przydatna. Z pozostałych elementów wyposażenia jedynie gniazdo słuchawkowe czasem szwankuje i stwierdza obecność słuchawek nawet, gdy nie są doń podłączone.

Jak zwykle rozpisałem się na temat, który nie jest aż tak istotny. Uznajmy jednak, że procesor Intel XScale (PXA250, 32-bitowy ARMv5TE) taktowany 400 MHz, 64 MiB RAM-u i 1 GiB karta SD wystarczają do wielu zadań. Natomiast Windows CE 4.20, czyli Windows Mobile 2003, w obecnych czasach reprezentuje ciemną stronę użyteczności. Zadanie, które sobie postawiłem, jest stosunkowo proste - znaleźć oprogramowanie FLOSS, lub freeware, które umożliwi mi sensowne korzystanie z tego reliktu techniki.

Software

Zacznijmy od gier. Od gry, którą chyba najbardziej najbardziej lubię spośród gier planszowych. Mowa o Go i programie Pocket GNU Go udostępnianym na licencji GPL. Wystarczy ściągnąć plik CAB dla procesorów ARM i zainstalować. Równie interesującą pozycją jest Palm Heroes, czyli palmtopowy odpowiednik Heroes of Might and Magic 2. Przez jakiś czas gra ta była znana pod nazwą Pocket Heroes i była oferowana za darmo. Obecnie twórcy życzą sobie za nią kilka dolarów, ale nadal w Internecie można znaleźć darmową wersję alfa, która nadaje się do gry. Co jeszcze? Można znaleźć wiele gier, ale warto zainteresować się emulatorem konsoli SNES. Mowa o PocketSNES bazującym na kodzie Snes9x (czuć GPL), który można pobrać w wersji przeznaczonej dla ARM ze strony domowej, lub w wersji zoptymalizowanej pod procesor XScale ze strony n0p. Polecam to drugie źródło.

Jak mówimy o grach to i o odtwarzaczach multimedialnych warto wspomnieć. Najlepszym odtwarzaczem na urządzenia mobilne jest zdecydowanie CorePlayer Mobile. Ma on jednak jedną zasadniczą wadę - jest oprogramowaniem, które należy zakupić. Bezpłatną alternatywą o równie sporych możliwościach jest TCPMP. Projekt ten będący starszym bratem CorePlayera, a dostępny na licencji GPL, został niestety porzucony na rzecz wersji płatnej, ale nadal sprawdza się w warunkach bojowych.

W przypadku potrzeby obsługi skompresowanych archiwów ZIP i RAR najlepiej skorzystać z Pocket RAR (freeware). Co prawda Rosjanie przygotowali już instalatory 7-zip dla Pocket PC, ale nie wygląda to jeszcze najlepiej.

Szyfrowanie? Można w tym celu wykorzystać FreeOTFE4PDA, czyli odpowiednik windowsowego FreeOTFE na Windows Mobile. Trudno jednak określić, czy szyfrowanie danych zawartych na PDA może się komukolwiek przydać. Niemniej jednak całość opiera się na zaszyfrowanych kontenerach, z których po zamontowaniu można korzystać, jak ze zwyczajnego nośnika. Szyfrowanie odbywa się w locie i będąc transparentnym nie tworzy problemów ze współpracą z innymi programami.

Co z aplikacjami codziennego użytku? Czy istnieje wolna, lub darmowa alternatywa dla narzędzi dostarczanych przez Microsoft? Niestety, sam z chęcią bym skorzystał z darmowego zamiennika dla standardowego kalendarza, Worda czy też Excela, których projektanci nie uwzględnili ergonomii pracy z nimi. Niestety, nic takiego jeszcze nie znalazłem chociaż w dalszym stopniu szukam.

W przypadku czytników PDF-ów całkiem nieźle sprawdza się PocketXpdf dostępny na licencji GPL. Przetestowałem go na pliku PDF o objętości ponad 3 MiB wygenerowanym przez LaTeX-a (zdjęcia oraz polskie znaki diakrytyczne). Efekt był zadowalający, a opcja wyświetlania samego tekstu mocno ułatwiła czytanie dokumentu. Zawsze można też skorzystać z Adobe Reader dla urządzeń mobilnych (freeware), który jest niestety sporych rozmiarów.

Z aplikacjami do quasi-nawigacji wspierającymi mapy z OpenStreetMap jest już nieco łatwiej. Wystarczy zajrzeć na wiki projektu. Chociaż znalezienie takiej, która faktycznie ruszy pod WM2003 to już zadanie dla wytrwałych.

Podsumowanie

Wymieniona przeze mnie lista programów z pewnością nie jest pełna. W przypadku, gdybyście mieli sugestie dot. istnienia przydatnego oprogramowania, zgodnego ze starszymi wersjami Windowsa Mobile, proszę o informację w komentarzach. Myślę, że warto taką listę rozwijać, szczególnie, że starsze palmtopy nadal mogą być pomocne i to za zdecydowanie niższą cenę, niż w przypadku nowszych urządzeń.

I should be able to whisper something in your ear, even if your ear is 1000 miles away, and the government disagrees with that.

Phil Zimmermann, twórca PGP

Spoglądam na to, co dzieje się wokół mnie i nie mogę uwierzyć w to, co widzę. Obawiam się, że tam, gdzie wkracza dostatecznie rozwinięta technologia, pojawia się wiele problemów z którymi ludzie nie są w stanie sobie poradzić. I to tylko i wyłącznie dlatego, że nie posiadają odpowiedniej wiedzy na dany temat. Za przykład weźmy BitTorrenta i serwery będące jego trackerami. W świecie, który funkcjonuje w sposób w miarę rozsądny, gdybym był stróżem prawa, ucieszyłbym się na myśl o tym, że ktoś wydał książkę telefoniczną z numerami przestępców. Złoczyńcy sami je dostarczyli, wystarczyłoby teraz odszukać każdego z nich, zebrać dowody i wytoczyć każdemu proces. Nawet przez myśl by mi nie przeszło, aby zamknąć wydawcę takiej książki. W obecnym świecie i z trackerami jest już nieco inaczej. Wygląda na to, że kosztem utraconych korzyści znacznie łatwiej obarczyć twórcę trackera, czyli wspomnianego wydawcę książki telefonicznej. Dlaczego?

Czyżby proceder ten był na tyle rozwinięty i społecznie akceptowany, iż walka z tysiącami pojedynczych osób byłaby zbyt kosztowna? Zdecydowanie łatwiej jest uderzyć w twórcę trackera. To kwestia pieniędzy. Nie o tym jednak chciałem pisać. Sam jestem gorącym zwolennikiem przestrzegania zarówno osobistych, jak i majątkowych praw autorskich. Bez względu na to, czy potencjalny odbiorca nie ma pieniędzy, czy też ma po prostu syndrom chomika. Mam natomiast spore obiekcje w stosunku do długości obowiązywania tych praw, co tyczy się również patentów i szeroko pojmowanej własności intelektualnej. Tak, czy inaczej, trzymam się prawa. To nie kwestia moralności, czy też strachu przed wymiarem sprawiedliwości. To kwestia zasad, które sam wykreowałem i do których się stosuję. Dlatego też...

Warto wspomnieć w tym kontekście o szyfrowaniu i prywatności. Zacznijmy od kryptografii, która jest czymś, co mocno zaburza równowagę sił między obywatelem, a państwem i jego organami. Błąd! Równowagi nigdy nie było. Dostępność kryptografii sprawia, iż waga i siła państwa nie jest w stanie zagrozić jednostce - szala przechyla się w stronę osoby wykorzystującej kryptogramy. Asymetria ta z pewnością musi być bolesna dla wszelkiej władzy. I tutaj pojawia się problem. Każdy z nas ma prawo do wolności, a prywatność jest jej częścią. Kryptografia natomiast ułatwia jej egzekwowanie. Bez względu na to, czy szyfrujemy śmieci, zeznania podatkowe, dokumenty, zdjęcia rodzinne, czy też intymne listy miłosne wiemy, iż dla osób niepowołanych dostęp do nich będzie mocno utrudniony. Utrudnia to jednak kontrolę i umniejsza władzę osób stojących wyżej w społecznej hierarchii.

Ktoś mógłby się zapytać, czego się boimy, że musimy szyfrować nasze dane. A może się wstydzimy? Nie mamy zaufania do otoczenia? Są to jednak pytania równie sensowne, jak pytanie dot. zamykania drzwi do domostwa, czy też wykonywania kopii zapasowych naszych danych. Każdy z nas ma prawo do prywatności. Jednak nie każdy tak uważa. Coraz częściej spotykam się z opinią, że szyfrowanie oznacza strach i chęć ukrycia czegoś przed otoczeniem. Tutaj jeszcze nie widać błędu w toku rozumowania, ale zaraz go dostrzeżemy. Ci sami ludzie uważają, że strach i chęć ukrycia czegoś jednoznacznie wskazuje na to, iż popełniono przestępstwo. Idąc tym tokiem rozumowania, oznacza to, iż człowiek praworządny nie ma potrzeby szyfrowania danych. Czyż nie brzmi to okropnie?

Wygląda na to, że wielu zagalopowało się w trosce o dobro ogółu, zapominając o wolności jednostek. Jeżeli ktoś z szanownych Czytelników sądzi, że to, o czym piszę jest abstrakcją niech zainteresuje się prawem panującym w Rosji, Francji, Iranie, czy też Iraku. Z tego, co się orientuję, to w krajach tych istniały i prawdopodobnie nadal istnieją obostrzenia dot. wykorzystywania kryptografii przez obywateli na użytek własny.

Nie popieram przestępczości i jej ukrywania. Popieram jednak prywatność i dlatego też, ze swojej strony, polecam zapoznanie się z takimi rozwiązaniami, jak OpenPGP, PKI, wieloplatformowym GPG, windowsowym TrueCrypt, czy też linuksowymi DM-Crypt (LUKS) oraz EncFS.

Ktoś by mógł pomyśleć, iż poniższy fragment kodu w Javie ME wykonany na telefonie Sony Ericsson z wbudowanym GPS-em przekaże poprawne dane NMEA 0183 do zmiennej nmea.

package net._4zal.gps;
 
import javax.microedition.location.*;
 
public class GPS implements LocationListener {
 
	// ...
 
	public void locationUpdated(LocationProvider lp, Location location)
	{
		double lon = 0, lat = 0, alt = 0;
 
		if (location.isValid()) {
			QualifiedCoordinates c = 
				location.getQualifiedCoordinates();
 
			lon = c.getLongitude();
			lat = c.getLatitude();
			alt = c.getAltitude();
		}
 
		String nmea = location.getExtraInfo(
			"application/X-jsr179-location-nmea");
 
	}
 
  // ...
 
}

Miałby on rację, ale tylko w pewnym zakresie. Kod ten będzie niestety niekompletny, a zawierać będzie jedynie sentencje typu GSV. Na przykład:

$GPGSV,3,1,10,03,73,236,,06,73,185,,22,63,139,,19,53,292,43*7A

Są to informacje dot. m.in. położenia wykrytych satelitów GPS. Zaś to, co dla nas najważniejsze, czyli np. GLL (szerokość i długość geograficzna), nie znajdzie się w zmiennej nmea. Oznacza to, że dane NMEA tego typu należy samodzielnie wygenerować bazując na tym, co znajdziemy w klasie Location. Słodko, prawda?

$GPGLL,54.38379406929016,N,18.619401454925537,E,225444,A,*0F

I tym oto sposobem, chcąc stworzyć program w Javie, który byłby w stanie udostępnić wewnętrzny moduł GPS telefonu zewnętrznym urządzeniom poprzez Bluetooth (z wykorzystaniem NMEA) należy się nieco napracować. Przynajmniej w przypadku telefonów Sony Ericsson. Bazować można na kodzie javowej wersji GPSd (opartej o fragment Barbelo) - zbudowanie aplikacji wymaga jedynie Wireless Toolkita 2.5.2. Może w wolnej chwili pobawię się w stworzenie wersji pod SE.

Na marginesie - na dłuższą metę nie warto się bawić z zabawkami pokroju wspomnianych telefonów z GPS-em. Zewnętrzny moduł zapewnia zdecydowanie wyższy komfort użytkowania.

Wstęp

W obecnych czasach moduł GPS to nie tylko narzędzie ułatwiające nam dotarcie do celu. To również gadżet, z którym coraz to częściej mamy do czynienia kupując telefon komórkowy. Ja sam posiadam zarówno zewnętrzny moduł, jak i wspomniany moduł wbudowany w telefon. Jak sobie z nimi radzę pod Linuksem?

Telefon z wbudowanym GPS-em jako zew. moduł GPS

Jak już wspomniałem, coraz więcej obecnych telefonów zawiera wbudowany moduł GPS. Niestety, ich wykorzystanie jest mocno problematyczne ze względu na możliwości tychże telefonów. Przykładem może być używany przeze mnie Sony Ericsson C702, który zupełnie nie nadaje się do nieco bardziej poważnej pracy. Chciałbym go jednak do niej zmusić. Tylko jak? Idealnym rozwiązaniem byłoby udostępnienie takiego wbudowanego GPS-a na zewnątrz - np. netbookowi, czy też laptopowi. Niestety, funkcjonalność ta nie należy do standardowej funkcjonalności udostępnianej przez telefon. Jak sobie z tym poradzić? Istnieje rozwiązanie pod postacią aplikacji Symarctic ExtGPS przeznaczonej głównie dla telefonów firmy Nokia. Napisana w Javie umożliwia stworzenie usługi Bluetooth udostępniającej na zewnątrz dane generowane przez wewnętrzny moduł. Poniżej znajduje się przepis tego, jak wykorzystać ją do przekazywania danych do systemu Linux. Całość przetestowana na systemie Ubuntu 9.04 oraz telefonie SE C702.

Na początku w telefonie instalujemy aplikację Symarctic ExtGPS, włączamy moduł Bluetooth, a następnie uruchamiamy zainstalowany wcześniej program. Powinny zostać wyświetlone komunikaty z prośbą o zgodę na dostęp do BT oraz modułu GPS. Po akceptacji naszym oczom ukazuje się prosty interfejs zawierający dwa czerwone kółka. Pierwsze od góry oznacza stan sygnału odbieranego z satelitów. Zmieni się na zielony po ustaleniu pierwszej pozycji (w przypadku obsługi A-GPS i otwartej przestrzeni nie trwa to długo). Drugie kółko to stan połączenia z komputerem. Przejdźmy zatem do PC-ta z zainstalowanym Ubuntu. Pierwsze polecenie, które wykonamy pozwoli nam zlokalizować urządzenia BT w okolicy. W tym nasz telefon.

zal@karol:~$ hcitool scan
Scanning ...
	00:21:9E:6D:D7:1E	Pandora

W moim przypadku mowa o Pandorze. Teraz następuje wykonanie kolejnego polecenia umożliwiającego sprawdzenie, gdzie nasłuchuje program ExtGPS.

zal@karol:~$ sdptool search --bdaddr 00:21:9E:6D:D7:1E SP
Searching for SP on 00:21:9E:6D:D7:1E ...
Service Name: Serial Port 1
Service RecHandle: 0x2008002
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 2

Service Name: Symarctic ExtGPS
Service Description: Share phone's built-in GPS module via Bluetooth
Service Provider: Symarctic Solutions
Service RecHandle: 0x200800d
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x00000100-0000-1000-8000-00805f9b34fb)
  "RFCOMM" (0x00000003-0000-1000-8000-00805f9b34fb)
    Channel: 16

Usług może być znacznie więcej, ale nas interesuje "Symarctic ExtGPS". Ostatnia linia wyjścia wskazuje na to, iż usługa nasłuchuje na kanale 16. Utworzymy teraz urządzenie /dev/rfcomm0, które będzie powiązane z ww. usługą (generując dane NMEA 0183) i udostępni ją demonowi gpsd.

rfcomm connect 0 00:21:9E:6D:D7:1E 16

Jedno z czerwonych kółek, odpowiedzialne za stan połączenia BT, w aplikacji telefonicznej powinno zmienić kolor na zielony. Jeżeli wszystko poszło zgodnie z planem - można to sprawdzić wykonując polecenie cat /dev/rfcomm0 i obserwując wynik - to czas na demona. W kolejnej konsoli wystarczy wykonać poniższe polecenie.

gpsd -b -N -D 2 /dev/rfcomm0

Wykorzystane argumenty -N -D 2 oznaczają, iż zamiast pracować w tle, będzie on funkcjonować w pierwszym planie umożliwiając nam odczyt informacji związanych z jego funkcjonowaniem. Argument -b zapobiega zniszczeniu konfiguracji tańszych odbiorników GPS (np. GPS-009) po której konieczny jest restart urządzenia (np. poprzez całkowite wyładowanie baterii), aby mogło ono funkcjonować. Poprawność działania gpsd można również określić włączając program xgps, lub wykorzystując polecenie telnet localhost 2947, a po połączeniu przesyłając literę "r" oraz naciskając enter.

Teraz już wszystko działa. Wystarczy jedynie odpalić aplikację służącą do odbioru danych z demona i nanoszenia jej na mapę.

Uwaga! W przypadku niektórych modeli telefonów komórkowych ExtGPS nie sprawdza się najlepiej z tego względu, iż przesyła jedynie wiadomości NMEA 0183 typu GSV, co nie jest wystarczające do określenia naszego położenia. Dzieje się tak ze względu na wykorzystanie przez niego następującej metody w Javie getExtraInfo("application/X-jsr179-location-nmea"). Jest to przyczyną dla której moduł GPS z telefonu SE C702 nie zadziała, gdy korzystamy z powyższej instrukcji. Alternatywą dla ExtGPS może być otwarty GPSd napisany w Javie ME (pobierz). Również korzysta on z opisanej powyżej metody, ale ze względu na to, iż jest otwarty można samodzielnie go zmienić. Należy dokonać edycji poniższego pliku (znajdującego się w repozytorium Git).

src/org/barbelo/GPS.java

Modyfikacja metody private String get_nmea(Location location) sprowadza się do umieszczenia uzyskanych informacji o szerokości i długości geograficznej w ciągu znaków zgodnych z formatem NMEA. W wolnej chwili postaram się sam dokonać modyfikacji i umieścić na blogu gotową do instalacji wersję GPSd.

Zewnętrzny moduł GPS z interfejsem Bluetooth

Instrukcja dla zewnętrznych modułów GPS z dostępem poprzez BT jest niemal taka sama, jak powyższa. Jedyna różnica polega jedynie na tym, iż moduł taki wystarczy jedynie włączyć, a hasło BT, które jest wymagane do połączenia, jest zazwyczaj postaci "0000".

Wolne aplikacje związane z GPS-em

Mamy już strumień danych płynący od telefonu do naszego komputera. Jak go teraz wykorzystać? Należałoby skorzystać z aplikacji odbierającej dane od demona gpsd i wyświetlającej je w odpowiedniej formie, najlepiej na mapie. Spore mamy wymagania. Szczególnie, gdy weźmie się pod uwagę koszt komercyjnych rozwiązań i map w nich wykorzystywanych. Nie jesteśmy jednak na straconej pozycji. Oto dwa programy korzystające m.in. z danych dostarczanych przez projekt OpenStreetMaps, o którym opowiem nieco szerzej w dalszej części wpisu.

Pierwszym opisywanym programem jest TangoGPS dostępny m.in. w repozytorium Ubuntu. W głównej mierze korzysta on map tworzonych w ramach projektu OpenStreetMaps, ale istnieje możliwość pobrania zdjęć lotniczych dostarczanych przez projekt OpenAerialMap (opcja "Aerial") oraz topograficznych z projektu maps4free (opcja "Topo"). Nic też nie stoi na przeszkodzie, aby dodawać własne repozytoria z mapami. Całość jest w locie ściągana z Internetu wraz z poruszaniem się po mapie - można też jednorazowo ściągnąć wszystkie dane dot. map. Sam program jest intuicyjny w obsłudze i nie sprawia większych problemów.

GpsDrive to drugi program, również dostępny w repozytorium Ubuntu, korzystający nie tylko z OpenStreetMap (układ ulic), ale również mający możliwość wykorzystania zdjęć satelitarnych dostarczanych za darmo przez NASA Landsat (obraz terenu).

Polecam zapoznać się z jednym i drugim programem. Każdy z nich posiada zalety i wady, a wybór, które będziemy używać, zależy w dużej mierze od naszych potrzeb i preferencji.

Darmowe mapy, czyli...

OpenStreetMap to projekt tworzony w duchu Open Source przez społeczność, a mający na celu wykreowanie map wolnodostępnych map dla każdego z nas. Dlatego też nie tylko można je stamtąd pobierać, ale również tworzyć korzystając z zebranych przez siebie danych GPS bawiąc się tym samym w kartografa.

Co do pokrycia terenu przez takie mapy to niestety, nie dorównują one jeszcze komercyjnym rozwiązaniom i zapewne jeszcze sporo czasu upłynie nim będą. Nawet w większych polskich miastach należy spodziewać się wielu białych plam. Niemniej jednak lepsze takie rozwiązanie, niż jego kompletny brak.

Zakończenie

Szukając informacji w Internecie natknąłem się na wiele pytań dot. możliwości wykorzystania wbudowanego w telefon GPS-a w roli zewnętrznego urządzenia podpinanego do PC-ta. Mam nadzieję, iż mój opis pomoże w głównej mierze tego typu osobom, a mi samemu ułatwi poruszanie się po mieście, którego nie znam, a do którego mam zamiar się udać.

W przypadku uwag, czy też wątpliwości, proszę śmiało komentować. Byleby konstruktywnie.

W zeszłym roku, po nalocie Policji na akademiki PG, mieliśmy akcję *uj. W tym roku jest zdecydowanie bardziej kulturalnie, ale równie smutno. Emotikona :(

Dzięki Airborn za podesłanie zdjęcia!

Wspominałem już, że lubię organizować sobie czas w trakcie wakacji? Nie inaczej jest i w tym roku. Po ponad miesięcznej rekrutacji otrzymałem wczoraj pozytywną odpowiedź od organizatorów Letnich Praktyk Badawczych 2009. Oznacza to, iż już za dwa tygodnie, a precyzyjniej 1 lipca, przenoszę się na trzy miesiące do Warszawy, aby odbyć praktykę w IBS PAN (mapka). Czym będę się tam zajmować?

Tak właściwie to jeszcze nic na ten temat nie wiem. Jedynymi wskazówkami są pytania na które udzieliłem odpowiedzi podczas tegorocznej rekrutacji oraz sprawozdania z poprzednich edycji LPB. Patrząc z mojej perspektywy, wygląda to na interesujące połączenie nauki z rzeczywistymi problemami biznesowymi związanymi m.in. z Internetem, bezpieczeństwem systemów komputerowych, kryptografią oraz zarządzaniem projektami naukowymi. Jest to dla mnie szczególnie ważna praktyka z tego względu, iż ostatnimi czasy rozważam możliwość wyboru naukowej ścieżki kariery. Natomiast połączenie jej z czymś bardziej konkretnym, w kategorii finansowej, byłoby z pewnością korzystne dla mnie.

Obecnie zastanawiam się na tym, gdzie zdołam znaleźć zakwaterowanie w ciągu najbliższych dwóch tygodni i co zabrać ze sobą na czas pobytu w Warszawie. Podejrzewam, że pozostanę przy próbie wynajęcia jednoosobowego pokoju w akademikach jednej z warszawskich uczelni oraz na zabraniu ze sobą laptopa, palmtopa i bramki VoIP. W razie potrzeby już na miejscu dokupię switcha, lub router.

Wstęp

Moje spojrzenie na system plików i dane w nim zawarte może być przez wielu postrzegane, jako nietypowe. Nie zależy mi na wydajności tj. prędkości zapisu i odczytu danych z dysku. Lubię natomiast, gdy moje dane są chronione przed wzrokiem niepowołanych osób (transparentne szyfrowanie), a przy okazji są w miarę odporne na uszkodzenia. Oczywiście, trudno mówić o tym, aby 111 GiB przenośny dysk 2.5″ był najlepszym rozwiązaniem, szczególnie jeżeli mowa o bezpieczeństwie. Pomińmy jednak tę kwestię i skupmy się na czymś innym.

Ostatnio opisywałem ZFS-a, który nie tylko dba o bezpieczeństwo danych (sumy kontrolne, transakcje itp.), ale również zapewnia coś, co przydaje się podczas składowania dużej ilości danych. Mowa o transparentnej kompresji danych.

Pojawiło się zatem w mojej głowie proste pytanie - jak najmniejszym kosztem uzyskać zarówno transparentne szyfrowanie, jak i kompresję danych na wspomnianym dysku? Czy da się to zrobić nieinwazyjnie, czy też czekają mnie większe zmiany w systemie operacyjnym i samym systemie plików?

Rozwiązanie

Rozwiązanie nie jest takie proste, jakby się to mogło wydawać. Czy istnieje uniwersalne rozwiązanie pasujące do każdego systemu plików? Odpowiedzią mógłby być compFUSEd oparty o FUSE. Należy mieć jednak na uwadze to, iż obecnie nie grzeszy on stabilnością i może się przyczynić do utraty danych. A może coś mniej uniwersalnego? Istnieją projekty e2compr (stabilne) oraz e3compr (niestabilne) dodające obsługę transparentnej kompresji do Ext2 oraz Ext3. To już coś. Natomiast o FuseCompress nie warto nawet wspominać.

Jak widać, o ile transparentne szyfrowanie danych przechowywanych w różnego rodzaju systemach plików nie stanowi większego problemu, tak kompresja w locie jest już kłopotliwa. Najbezpieczniej byłoby zatem wykorzystać system plików, który wspiera ten tryb pracy. Oto lista systemów plików lepiej, lub gorzej wspieranych przez Linuksa, które to umożliwiają:

• ZFS,
• Fossil,
• Reiser4,
• NTFS,
• Btrfs.

Spory wybór? Nie do końca. Btrfs jest dostępny obecnie jedynie w wersji rozwojowej i nieco czasu upłynie nim ukaże się jego wersja stabilna. NTFS jest obsługiwany w Linuksie poprzez NTFS-3g (FUSE), który nie obsługuje zapisu na skompresowanych/szyfrowanych partycjach NTFS. ZFS również jest obsługiwany przez Linuksa poprzez FUSE, a ZFS-on-FUSE od jakiegoś czasu nie jest już rozwijane. Reiser4 nigdy nie wszedł do jądra Linuksa i wymaga nałożenia łat na jądro. A Fossil? Egzotyczny system plików stosowany w systemie Plan 9 from Bell Labs, a dostępny pod Linuksem dzięki wykorzystaniu plan9port.

Wybór? Trudny. Do tej pory korzystałem z ZFS-on-FUSE, gdzie kompresja nie jest problemem, ale praca na dysku przenośnym może nie należeć do przyjemnych. Pozostaje Reiser4, Btrfs oraz Ext2 z e2compr. Zarówno Reiser4, jak i e2compr wymagają nałożenia łat na jądro. Btrfs jest już natomiast wspierane (eksperymentalnie) przez jądro 2.6.29. Wykorzystamy zatem Btrfs. Warto jednak pamiętać, że zarówno Btrfs, jak i ZFS-on-FUSE to obecnie rozwiązania eksperymentalne i nijak się mają do bezpieczeństwa, o którym pisałem na początku.

Czym jest Btrfs?

Btrfs to innowacyjny system plików przeznaczony dla Linuksa. Rozwijany przez Oracle, a dystrybuowany na licencji GPL, stanowi odpowiedź na system ZFS wydany na licencji CDDL przez Sun Microsystems. Oto główne cechy Btrfs:

• obsługa plików o rozmiarach do 16EB,
• transakcyjne operacje,
• rozszerzenie idei LVM podobne do ZFS-owych pul,
• łatwe tworzenie przyrostowych kopii bezpieczeństwa,
• przechowywanie sum kontrolnych (obecnie CRC-32C) zarówno dla danych, jak i metadanych celem wykrywania błędów,
• wsparcie dla transparentnej kompresji danych,
• wykorzystanie techniki kopiowania przy zapisie,
• tryb przeznaczony do minimalizacji zużycia dysków SSD,
• i wiele innych.

Należy mieć na uwadze, iż obecnie system ten trafił już do jądra systemu Linux (od wersji 2.6.29-rc), ale znajduje się jeszcze w fazie eksperymentalnej. Minie jeszcze sporo czasu, nim światło dzienne ujrzy jego stabilna wersja. Do tego czasu należy zachować szczególną ostrożność i nie wykorzystywać Btrfs do przechowywania danych, które stanowią dla nas jakąkolwiek wartość.

Instalacja obsługi Btrfs pod Ubuntu 9.04

Na początku należy pobrać źródła jądra Linuksa w wersji 2.6.30 dla 32-bitowego procesora (dla 64-bitowego systemu należy samodzielnie zmodyfikować instrukcję) oraz paczki niezbędne do skompilowania źródeł i narzędzi do zarządzania systemem Btrfs.

sudo aptitude install build-essential kernel-package \
checkinstall uuid-dev zlib1g-dev e2fslibs-dev libacl1-dev bzip2 libncurses5-dev
 
mkdir ~/linux-2.6.30_i386
cd ~/linux-2.6.30_i386
 
wget http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.30/\
linux-source-2.6.30_2.6.30-020630_all.deb
 
sudo dpkg -i *

Teraz możemy przejść do konfiguracji, kompilacji i instalacji paczek z nowym jądrem.

cd /usr/src/
sudo tar -xvjf linux-source-2.6.30.tar.bz2
cd linux-source-2.6.30
 
# Kopia aktualnie używanej konfiguracji do nowego jądra.
sudo make oldconfig
 
# Tutaj następuje konfiguracja - należy w niej odznaczyć gwiazdką opcję:
# File systems -> Btrfs filesystem (EXPERIMENTAL) Unstable disk format
sudo make menuconfig
 
# Kompilowanie, tworzenie paczek i ich instalacja w systemie.
# Należy uzbroić się w cierpliwość.
sudo make-kpkg linux-image linux-headers --initrd
cd ..
sudo dpkg -i linux-headers-2.6.30_2.6.30-10.00.Custom_i386.deb
sudo dpkg -i linux-image-2.6.30_2.6.30-10.00.Custom_i386.deb

Po udanej instalacji nowego jądra przystępujemy do kompilacji i instalacji narzędzi do zarządzania Btrfs-em. Oczywiście, wykorzystane do tej pory źródła można bezpiecznie usunąć z dysku.

cd ~
wget http://www.kernel.org/pub/linux/kernel/people/mason/btrfs/\
btrfs-progs-0.18.tar.gz
 
tar -xvvzf btrfs-progs-0.18.tar.gz
cd btrfs-progs-0.18/
make
make convert
sudo checkinstall

Jeżeli wszystko poszło po naszej myśli - ponowne uruchomienie systemu odbędzie się już z naszym nowym jądrem i obsługą Btrfs.

Jeszcze jedna ważna uwaga. Btrfs-progs od wersji 0.19 obsługują nowy format Btrfs i w takim też formacie tworzą system plików na danej partycji. Do ich czytania potrzebne jest zmodyfikowane jądro Linuksa obsługujące ten format, które jest obecne dostępne jedynie w repozytorium Gita projektu Btrfs. Próba zamontowania nowego systemu plików z wykorzystaniem jądra bez obsługi tego formatu kończy się poniższym komunikatem w dmesg:

BTRFS: couldn't mount because of unsupported optional features (1).

Próba zamontowania systemu plików w starszej wersji w systemie, który obsługuje nowszą wersję kończy się... automatyczną konwersją systemu plików do nowszego formatu. Linus Torvalds miał z tym już spore problemy nie dalej, jak tydzień temu. Trzeba jednak przyznać, iż zastosowanie nowego formatu oraz narzędzi w wersji 0.19 i wyższej owocuje znacznym (niekiedy 3-krotnym) przyrostem prędkości.

Wykorzystanie

Nim stworzymy na naszym dysku system plików Btrfs warto się najpierw zastanowić, czy oczekujemy tego, aby był on zaszyfrowany. Jeżeli tak to najpierw należy zapoznać się z instrukcją tworzenia zaszyfrowanych partycji (DM-Crypt + LUKS) stworzoną przeze mnie. Dopiero na tak utworzonej i zamontowanej partycji możemy utworzyć docelowy system plików. A wymaga to tylko i wyłącznie jednej komendy:

sudo mkfs.btrfs /dev/urządzenie_blokowe

Proste, prawda? Aby się przekonać, czy wszystko poszło zgodnie z planem możemy wykorzystać poniższe polecenie, które powinno wyświetlić informacje o dostępnych partycjach z Btrfs-em.

sudo btrfs-show

A jak włączyć kompresję danych w tak utworzonym systemie plików? Wszystko zależy od tego, jak zamontowana zostanie taka partycja. Przykładowo:

sudo mount -t btrfs -o compress -o ssd /dev/partycja_btrfs /media/dysk

W ten sposób nie tylko włączymy kompresję (obecnie zlib) na zamontowanej partycji, ale również uaktywnimy tryb pracy dostosowany do pracy z dyskami SSD (uwzględniający ich zużycie).

Zakończenie

Mam nadzieję, iż przedstawione powyżej rozwiązanie okaże się pomocne i zachęci do zapoznania się nie tylko z Btrfs-sem, ale również z ZFS-em, czy innymi systemami plików, które są obecnie bardziej innowacyjne, niż popularny Ext2, Ext3, czy też nawet Ext4.

Na samo zakończenie chciałbym jeszcze raz zaznaczyć, iż zarówno projekt ZFS-on-FUSE, jak i Btrfs znajdują się obecnie w fazie rozwoju, a korzystanie z nich może stanowić realne zagrożenie dla przechowywanych z ich wykorzystaniem danych.