Karol „Zal” Zalewski

Gdyby ktoś miał ochotę zapoznania się z pierwszym polskim artykułem poświęconym ENIAC-owi to polecam do zajrzenia na strony Sekcji Historii Informatyki PTI. Znajduje się tam elektroniczna wersja artykułu z miesięcznika „Problemy” (nr 6 z 1946). Naprawdę warto go przeczytać chociażby po to, aby móc zobaczyć, jak bardzo różniło się spojrzenie ludzi sprzed ponad 60 lat na przyszłość informatyki względem tego, do czego dostęp mamy obecnie.

Bardzo podoba mi się inicjatywa polegająca na próbie skompletowania materiałów dot. historii informatyki. Zarówno tej światowej, jak i krajowej.

Posiadasz smartphone HTC Desire, dokonałeś aktualizacji OTA do Androida 2.2 (HBOOT 0.92.0001) podesłanej przez producenta i teraz nie jesteś w stanie uzyskać dostępu do roota? Istnieje rozwiązanie! Dzięki użytkownikom jednego z chińskich for udało się dokonać downgrade Androida 2.2 do 2.1 (HBOOT 0.80.0000). Po całej operacji wystarczy użyć programu Unrevoked³ celem nadpisania obrazu „recovery” oraz uzyskania dostępu do konta roota, a następnie wgrać zrootowany już ROM Androida 2.2. Oto opis procedury downgrade:

Przygotowanie

1. Stwórz nową Goldcard (angielski opis tworzenia pod Windowsem - pod Linuksem trzeba na końcu wykorzystać program dd),
2. Ściągnij PB99IMG.zip (mirror),
3. Zmień nazwę ściągniętego pliku na PB99IMG.zip i przekopiuj na kartę SD.

Flashowanie

1. Wyłącz telefon,
2. Trzymając wciśnięty klawisz Ciszej naciśnij włącznik zasilania,
3. Poczekaj aż PB99IMG.zip zostanie znaleziony i sprawdzony,
4. Naciśnij klawisz Głośniej (yes), gdy pojawi się pytanie dot. aktualizacji,
5. Poczekaj, aż wszystkie punkty zostaną wykonane. NIE WYŁĄCZAJ TELEFONU!
6. Po wykonaniu flashowania naciśnij klawisz Głośniej (yes), aby zrestartować telefon,
7. Gotowe.

Źródło: forum XDA-Developers

W ciągu ostatnich kilku dni zrobiło się stosunkowo głośno o rozpoczęciu działania na skalę globalną systemu DNSSEC. Wygląda na to, że w końcu zabezpieczono jeden z najsłabszych elementów Internetu, jakimi były DNS-y. Oczywiście, nie byłoby to możliwe bez wykorzystania osiągnięć kryptografii pod postacią szyfrów symetrycznych oraz asymetrycznych. Pojawia się tutaj jednak jeszcze jeden element, o którym warto wspomnieć. Jest to tzw. dzielenie sekretu. Cała siła systemu DNSSEC tkwi w kluczu głównym. Jego utrata bądź nieautoryzowany dostęp do niego naraziłyby na szwank cały Internet. Prosty backup nie wchodził zatem w grę. Zdecydowano się wykorzystać protokół dzielenia sekretu. Poniżej znajduje się krótki i przystępny opis tej koncepcji.

Postanowiono podzielić klucz na 7 części (rozdano je różnym osobom z całego świata) tak, aby do jego odzyskania wystarczyło 5 dowolnych fragmentów. Odtworzenie klucza przy pomocny mniejszej liczby części, czyli tzw. cieni, miało być niemożliwe do wykonania. Proces ten najłatwiej opisać w oparciu o protokół Blakleya. W uproszczeniu można to przedstawić w następujący sposób. W przestrzeni trójwymiarowej, aby określić położenie konkretnego punktu należy posłużyć się trzema różnymi, nierównoległymi płaszczyznami. Oczywiście, takich płaszczyzn przechodzących przez ten punkt można wygenerować nieskończenie wiele, ale trzeba posiadać, co najmniej trzy by móc go odtworzyć. Nasz sekret to jedna ze współrzędnych tego punktu (np. X). Mniejsza liczba płaszczyzn nie pozwala na odkrycie żadnej wskazówki dot. naszego sekretu (w przypadku przecięcia się dwóch płaszczyzn otrzymujemy prostą). Manipulując liczbą wymiarów, w których znajduje się punkt, manipulujemy również liczbą płaszczyzn wymaganych do jego odtworzenia. Zatem w przypadku DNSSEC wygenerowano 7 płaszczyzn dla każdego punku umieszczonego w przestrzeni pięciowymiarowej. O ile skorzystano z protokołu Blakleya.

Powyższe podejście jest stosunkowo prymitywne, nieodporne na oszustwa (spróbujcie podłożyć fałszywą płaszczyznę i określić, która z nich jest oszustwem nie znając prawidłowego punktu), ale zapewnia pożądaną nadmiarowość i większe bezpieczeństwo, niż próba podzielenia sekretu na części w sposób intuicyjny (np. hasło „sekret” dzielimy na trzy fragmenty - „se----”, „--kr--” i „----et”). Istnieją protokoły umożliwiające wykrywanie oszustwa (a nawet konkretnych oszustów) oraz np. określenie maksymalnej liczby cieni wymaganych do odtworzenia pierwotnej wiadomości. Możliwe jest także tworzenie bardziej skomplikowanych rozwiązań, kiedy to poszczególni posiadacze cieni mają różną wagę „głosu” (np. dwóch generałów lub dwudziestu oficerów wystarcza do odtworzenia sekretu). Cała koncepcja z punktu widzenia teorii informacji ma swoje ograniczenia, ale jest wykorzystywana w praktyce np. do tworzenia kopii kluczy prywatnych OpenGPG. Ja sam interesuję się nią ze względu na możliwość wykorzystania jej przy tworzeniu bezpiecznych, niezawodnych i zdecentralizowanych baz danych np. dla systemów agentowych.

Osobom zainteresowanym tą tematyką polecam zajrzenie do publikacji autorstwa Bruce Schneiera (np. do bardzo popularnej jego książki pt. „Kryptografia dla praktyków”). Dobrym punktem wyjścia jest również anglojęzyczna Wikipedia.

Jak już wspomniałem kilka dni temu udało mi się ostatnio zakupić smartphone HTC Desire z Androidem 2.1 i HTC Sense UI na pokładzie (specyfikacja dostępna na stronach producenta). Z początku trudno było mi jednoznacznie stwierdzić, czy jestem zadowolony z zakupu. Obecnie, po kilku dniach korzystania, jestem w stanie zweryfikować moje poglądy. Oto i krótka oraz zdecydowanie subiektywna recenzja tego telefonu. Zapraszam do lektury.

Myślę, że każdy, kto zastanawia się nad kupnem HTC Desire powinien najpierw przeczytać artykuł na Engadget.com. Znajdziecie tam m.in. kompletny opis zawartości pudełka, podzespołów telefonu oraz oprogramowania. W ogólności, autor recenzji pomimo dostrzeżenia kilku wad tego telefonu nadal jest pod jego wrażeniem. Ja również jestem i zgadzam się z nim, co do wymienionych przez niego zalet, ale... Poniżej znajduje się spis elementów, którym przyjrzałbym się jeszcze raz kupując ten sprzęt. Oto i on:

• bateria - Desire nie jest przeznaczony dla osób przyzwyczajonych do tego, że telefon służy po prostu do dzwonienia. Owszem, Desire może służyć za telefon. Jednak znacznie lepiej radzi sobie w roli lampki nocnej będąc na stałe przyczepionym do ładowarki. Żywotność tego telefonu na w pełni naładowanej baterii oraz przy wyłączonych modułach pokroju WiFi to circa 30h. Przy intensywnej zabawie wartość ta spada do około 12h. Zdecydowanie odbiega to od ponad 300h w trybie czuwania zadeklarowanych przez producenta. Chyba, że nigdy nie udało mi się osiągnąć stanu czuwania.
• optyczny trackball - nie tylko manipulator, ale również czujnik ruchu. Jest futurystyczny i robi dobre wrażenie. Przynajmniej do czasu, kiedy to zajdzie potrzeba jego intensywnego wykorzystania. Niestety, zupełnie nie sprawdza się w tej roli. Trudno go wyczuć palcami, co oznacza, że wymaga skupienia ze strony wzroku. Co więcej, trudno się nim sprawnie posługiwać - nierzadko otrzymujemy ruch kursora w kierunku obróconym o 90° względem oczekiwanego. Jeżeli ktoś oczekiwał, że wykorzysta swoją nową zabawkę do gry to srodze się zawiedzie.
• klawiatura ekranowa - kwestia gustu, ale jeżeli ktoś ma ochotę wykorzystywać telefon w roli konsoli do gier lub przenośnego Linuksa to radzę zastanowić się nad telefonami wyposażonymi w sprzętową klawiaturę. Jeżeli już podjęliśmy decyzję o klawiaturze ekranowej to należy zauważyć, iż jej działanie w dużej mierze zależy od oprogramowania służącego do jego obsługi, a o tym wspomnę już za chwilę.
• HTC Sense UI - ta nakładka na interfejs użytkownika robi wrażenie. Wszystko staje się kolorowe, błyszczące i animowane, a do tego udostępnia kilka aplikacji umożliwiających łatwą integrację z Twitterem, Facebookiem itp. serwisami. Również i klawiatura ekranowa za jej sprawą nabiera zupełnie nowego charakteru. Szkoda tylko, że jest niedopracowana, a konieczność jej integracji z systemem opóźnia wydanie przez HTC aktualizacji Androida do wersji 2.2.
• Android 2.1 - śmiga. Cały system dostaje czkawki tylko i wyłącznie w momencie, gdy instaluję równocześnie kilka aplikacji z Android Market lub korzystam z aplikacji dostarczonych w ramach HTC Sense. Należy też zaznaczyć, że aktualizacja systemu do wersji 2.2 byłaby wskazana chociażby ze względu na możliwość instalacji aplikacji na karcie SD. Wierzcie mi, że wewnętrzna pamięć telefonu jest zbyt mała na to, aby pomieścić wszystkie użyteczne aplikacje z Android Market.
• producent (HTC) - nie liczcie na to, że coś od niego uzyskacie. HTC już kilka razy pokazało, co sądzi o swoich klientach opóźniając wydanie lub nigdy nie wydając aktualizacji oprogramowania dla swoich telefonów. Kupując sprzęt tego producenta warto mieć na uwadze to, że trzeba liczyć na społeczność, gdy chce się mieć aktualny system. Na całe szczęście, pomimo stosowania pewnych zabezpieczeń chyba jeszcze żadne z nich nie okazało się na tyle silne, aby uniemożliwić instalację systemów udostępnionych przez niezależnych dostawców.
• Google - pierwszy zarzut pod adresem Google to brak dostępu do płatnej części Android Market. Telefon z Androidem na pokładzie bez aplikacji z Android Market jest namiastką tego, czym może się stać i dobrze, że zachowano przynajmniej dostęp do jego części. Co prawda do płatnej części można się dostać uzyskując dostęp do roota (tzw. „rootowanie” systemu) oraz instalując stosowne oprogramowanie (np. MarketAccess), ale... To nie jest miłe zagranie ze strony Google. Można też mieć zarzut do sposobu w jaki funkcjonuje integracja telefonu z kontem w systemie Google. Synchronizacja kontaktów z Google Contacts bywa irytująca, szczególnie po „usprawnieniu” jej przez HTC Sense.

Podsumowując, HTC Desire to dobry smartphone. Szczególnie, jeżeli nie przeszkadza nam czas działania na baterii oraz wątpliwe wsparcie ze strony producenta. Idealnie nadaje się do buszowania w Internecie, czy też nawigacji (wbudowany GPS, magnetometr oraz akcelerometry). Co więcej, jako urządzenie bardzo podobne pod względem specyfikacji do Nexus One można oczekiwać, że długo będzie wspierane przez twórców niezależnych dystrybucji Androida, a samo wgrywanie nowego oprogramowania pozostanie trywialne (dzięki unrevoked oraz ROM Manager). Trzeba być jednak świadomym tego, że nie jest to urządzenie idealne. Pomimo drzemiącej w nim mocy (układ Snapdragon taktowany zegarem o częstotliwości 1GHz ze zintegrowanym akceleratorem 3D) pozostanie ona najprawdopodobniej niewykorzystana.

[EDIT] Brak wsparcia dla Javy ME też bywa bolesny, a multitouch ograniczony do wykrywania odległości między dwoma palcami irytujący.

Systemy kontroli wersji pokroju SVN, Mercuriala, czy też Gita to świetne rozwiązanie, które znacząco ułatwia nie tylko samodzielną pracę nad projektami informatycznymi, ale również sprzyja pracy grupowej. Chyba każdy, kto miał okazję wspólnej pracy nad treścią dłuższego dokumentu doceni połączenie LaTeX-a oraz któregoś z wymienionych systemów. Istnieją jednak takie sytuacje, kiedy to systemy kontroli wersji zupełnie nie sprawdzają się. Ostatnie chwile przed deadlinem, kiedy to cała grupa intensywnie pracuje nad dokumentem, są źródłem konfliktów, które co i rusz należy rozwiązywać. A przecież blokada konkretnego pliku w tak delikatnym okresie nie wchodzi w grę. Jak sobie z tym poradzić? To proste. Wystarczy skorzystać z „notatnika w wersji multiplayer”. Oto krótki opis oprogramowania, które dostarcza wspomnianą funkcjonalność i znacząco ułatwia pracę w zespole.

Kiedyś już wspominałem o polskim projekcie o nazwie MoonEdit. Program ten, o zamkniętym kodzie źródłowym (freeware do użytku niekomercyjnego), będąc narzędziem wieloplatformowym umożliwia wspólną edycję jednego pliku przez kilka osób w tym samym czasie. Wszystko odbywa się w czasie rzeczywistym, a zmiany oznaczane są kolorami przyporządkowanymi do użytkownika, który danej modyfikacji dokonał. Świetna sprawa, która w znaczący sposób ułatwia wspólną pracę nad jednym dokumentem. Przypomina to w pewnym stopniu to, co mogą zaobserwować użytkownicy usług Google o nazwie Google Docs (ew. LaTeX Lab - otwartoźródłowy edytor LaTeX-a oparty o Google Docs) oraz Google Wave. Wszystkie te rozwiązania mają jednak co najmniej jedną, acz istotną, wadę. Ich licencje oraz sposób funkcjonowania sprawiają, iż ich wykorzystanie jest ograniczone. Warto zatem poszukać wolnego oprogramowania, które pełni rolę takiego sieciowego notatnika. Takim programem jest Gobby.

Gobby to wieloplatformowy projekt rozwijany od 2005, a dostępny na licencji GPL, który całkiem nieźle sprawdza się podczas grupowej edycji dokumentów. Szczególnie, jeżeli mowa o kodach źródłowych oraz plikach z kodem w LaTeX-u. Możliwość pracy na kilku plikach jednocześnie, osobny kanał komunikacyjny dla osób uczestniczących w tworzeniu (coś ala IRC), szyfrowane połączenia, ochrona pliku hasłem, podświetlanie składni, czy też wsparcie dla Unicode to tylko niektóre z cech Gobbiego. Samą aplikację znajdziecie w repozytoriach takich dystrybucji Linuksa, jak np. Debian, czy też Ubuntu. Warto również podkreślić, że Gobby ułatwia pracę deweloperom podczas Ubuntu Developer Summit. Także członkowie projektu Fedora mają z nim stosunkowo często do czynienia.

Gdybyście mieli ochotę zapoznać się z Gobbim to polecam na sam początek wypróbować wersję starszą, niż 0.4.90. Dlaczego? Starsze wersje pomimo braku funkcjonalności redo/undo posiadają nieco prostszy interfejs użytkownika oraz serwer wbudowany w klienta, który można uruchomić jednym kliknięciem myszy (serwer dedykowany tj. Sobby jest opcjonalny).

Zachęcam do wypróbowania Gobbiego lub innych rozwiązań tego pokroju. To naprawdę ułatwia pracę i umożliwia skupienie się na tym, co najważniejsze bez potrzeby tracenia energii na zabawę w rozwiązywanie konfliktów, czy siedzenie przed jednym komputerem.

Czy byłby to dla mnie problem, gdybym miał dobrowolnie przekazać 1, 2, lub 5 złotych twórcy, który udostępnił za darmo stworzony przez siebie tekst, obraz, muzykę, film, grę, czy też program? Jeżeli utwór ten byłby w moim mniemaniu dobry to „why not?”. Ale jak tylko pomyślę, że aby przekazać komuś 1 złoty musiałbym poszukać jego numeru konta, danych osobowych, uruchomić interfejs WWW mojego banku, wypełnić formularz, poczekać na token pod postacią SMS-a i... To mi się odechciewa. Za dużo tego, prawda? A gdyby tak zrobić to prościej, szybciej i z większym pożytkiem zarówno dla twórców, jak i odbiorców?

Gdybym mógł przekazać twórcy złotówkę przy pomocy jednego kliknięcia to nie tylko ja byłbym zadowolony, ale i twórca mógłby liczyć na więcej darowizn. Sama koncepcja płatności przez Internet jest prosta i dobrze znana. Wystarczy spojrzeć na takie serwisy, jak np. PayPal, MoneyBookers, Google Checkout oraz Amazon Payments. Nieco większym problemem przy korzystaniu z ww. usług jest rola obdarowanego oraz integracja z kontami bankowymi. Niestety, koszty jakie ponosi obdarowany oraz trudność w przelewaniu środków na konta ww. systemów w celu skorzystania z nich przez darczyńców (np. wymagane posiadanie karty kredytowej lub doładowanie wirtualnego konta tradycyjnym przelewem) sprawiają, że nie nadają się do realizacji celu, o którym napisałem.

Przykład rozwiązania w oparciu o system Dotpay.pl - metoda POST. Bez potrzeby zakładania odrębnego konta ze strony darczyńcy. Istnieje również możliwość skorzystania z metody GET.

A może rodzime rozwiązania lepiej sprawują się pod tym względem? Trochę ich jest - Platnosci.pl, PayU, Przelewy24 i Dotpay. Po krótkim przejrzeniu ich możliwości oraz warunków na jakich działają większość z nich odpada w przedbiegach, pozostaje Dotpay. Tak, jak i inne serwisy, dzięki integracji z polskimi systemami bankowymi umożliwia on dokonywanie szybkich wpłat przez darczyńców. Jest również przystosowany do przekazywania darowizn - nie wymaga od twórcy prowadzenia działalności gospodarczej, ani tworzenia konta w ich systemie przez darczyńcę. Odbierający darowiznę obarczany jest opłatą w wysokości kilku procent od przelewanej kwoty (minimum 30 groszy). Rejestracja konta odbiorcy kosztuje 10 złotych i jest konieczny do odebrania zgromadzonych pieniędzy na tradycyjne konto (sam przelew to złotówka). Wady? Wysoka minimalna opłata za przekazanie pieniędzy oraz brak anonimowości ze strony darczyńcy (np. konieczność podania imienia i nazwiska). Zalety? Darczyńca nie musi posiadać karty kredytowej (wystarczy ROR w jednym z polskich banków) lub doładowywać konta w systemie. W razie potrzeby może on wykorzystać również kilka innych systemów w celu zrealizowania płatności (standardowo MoneyBookers, dodatkowo PayPal). Jedno kliknięcie i trafia się na stronę, która pozwala na wybór sposobu płatności oraz podanie podstawowych danych osobistych (zazwyczaj imię, nazwisko i e-mail). Po niej następuje logowanie w systemie naszego banku i... Pozostaje jeszcze kwestia hasła jednorazowego (w przypadku np. mBanku), którego obecność utrudnia procedurę, a ewentualny brak powoduje zmniejszenie bezpieczeństwa.

Hasło jednorazowe. Jak je usunąć nie tracąc bezpieczeństwa? To proste! Wystarczy wprowadzić limit darowizn, jaki można zrealizować w ciągu dnia. Jaki i czego dotyczący (tj. suma darowizn, liczba darowizn, liczba darowizn przekazanych danemu użytkownikowi itp.) to już inna kwestia. Tego brakuje. Ostatniego elementu, z punktu widzenia informatyka (US miałby pewnie odmienne zdanie), niezbędnego do stworzenia systemu sprzyjającego przekazywaniu mikrodarowizn twórcom funkcjonującym w polskim Internecie. Niestety, decyzja nie leży po stronie użytkownika, a po stronie twórców systemów bankowych.

Pomysł nie jest szczególnie odkrywczy, ale jestem ciekaw, co o tym sądzicie. Czy również dostrzegacie bariery na jakie natrafia osoba chcąca przekazać piątaka twórcy? Czy sądzicie, iż ich zniesienie może wpłynąć na liczbę darowizn i być korzystne dla twórców? Moim zdaniem wyeliminowanie tych barier jest ważne. Szczególnie, że rozwiązania „zapłać tyle, ile chcesz” stają się coraz popularniejsze pośród niezależnych twórców i sympatyków wolnej kultury, a łatwość przekazywania darowizn i ich odbioru ma kluczowe znaczenie w takim środowisku.

Jedna z moich ostatnich zabawek (telefon Nokia E51) umożliwia drukowanie notatek, kalendarzy, SMS-ów itp. korzystając z drukarek sieciowych. Robi to stosując HP JetDirect lub protokół LPR. Oznacza to, iż aby możliwym było drukowanie z wykorzystaniem drukarki udostępnianej na serwerze z CUPS-em należy tak go skonfigurować, aby zachowywał się, jak LPD.

W tym celu, pod Linuksem (w moim przypadku jest to Debian), należy dodać do /etc/inetd.conf (plik konfiguracyjny super serwera) następującą linię:

Po zapisaniu pliku wystarczy zrestartować inetd (pod Debianem: /etc/init.d/openbsd-inetd restart). Konfigurując drukarkę w telefonie komórkowym podajemy adres IP lub nazwę hosta serwera oraz nazwę drukarki w systemie CUPS. Przykładowo, dostęp do drukarki z poziomu CUPS-a uzyskuję dzięki adresowi:

Oznacza to, że w nazwie hosta wpiszę thor.ipv4.4zal.net, zaś w przypadku kolejki użyję Officejet_Pro_K550. Jeżeli dodatkowo jest to drukarka firmy HP to mogę użyć w komórce sterownika o nazwie HP Mobile Printing. Wydruki będą ładniejsze, a polskie znaki diakrytyczne nie będą sprawiać żadnych problemów.

Efektem ubocznym takiej konfiguracji CUPS-a jest to, iż od teraz każdy, kto posiada informacje o serwerze oraz wykorzystywanej kolejce będzie w stanie drukować na niej bez potrzeby dokonywania uwierzytelniania i autoryzacji.

Wygląda na to, że w kolejnej wersji Ubuntu przeznaczonego na netbooki, czyli Ubuntu Netbook Remix 10.4, pojawi się wsparcie dla usługi Google Docs. Co więcej, domyślnie zastąpi ona aplikację OpenOffice.org. I tutaj moim skromnym zdaniem pojawia się problem, który należałoby ugryźć z nieco szerszej perspektywy.

Usługi z chmur (tj. SaaS) to nie tylko popularna obecnie forma udostępniania oprogramowania (konkretniej - jego funkcjonalności), ale również powrót do korzeni informatyki, kiedy to królowały ogromne maszyny typu mainframe oraz terminale umożliwiające komunikację z nimi. Maszyny takie nie tylko udostępniały oprogramowanie i moc obliczeniową użytkownikom, ale również miejsce na ich prywatne dane. Pomimo wprowadzenia pewnej decentralizacji (zamiast mainframe mamy „chmurę”) i formy komunikacji (sieć lokalna wyparta przez sieć globalną) obecne rozwiązania są bardzo podobne do koncepcji sprzed kilku dekad. Co to oznacza? Przede wszystkim to, iż równie aktualne pozostają problemy, które miały miejsce i wtedy.

Ochrona prywatności i odpowiedzialność za dane użytkowników jest chyba najbardziej palącym problemem. Udostępniając komuś nasze prywatne dane musimy mieć pewność tego, iż powierzamy je w dobre ręce. Nie chcemy, aby ktoś nam w nich grzebał, udostępniał osobom trzecim, czy też utracił i nie był zdolny do ich przywrócenia. Oddając nasze dane osobom trzecim zawsze jesteśmy na to narażeni, nawet jeśli warunki korzystania z usługi dają nam pewną ochronę. Dlaczego? Firma nie stanowi bytu oderwanego od rzeczywistości. Często też korzysta z usług innych firm, a sama w sobie operuje w środowisku, które w dużym stopniu jest podatne na działania ze strony państwa. To, co dla nas jest naturalne może wyglądać zupełnie inaczej w państwie po drugiej stronie globu.

Konieczność działania w trybie online to również istotny problem. Usługa to nie to samo, co samodzielnie działając oprogramowanie. W celu jej wykorzystania konieczny jest dostęp do usługodawcy, a urządzenia, szczególnie te mobilne, pomimo i tak znacznej elastyczności w zakresie dostępu do Sieci nadal mogą działać w oderwaniu od niej. Jak wtedy poradzić sobie z dostępem do danych w chmurze oraz usług?

SaaS to również idealna koncepcja dla producentów oprogramowania. Owszem, wymaga to od nich pewnego nakładu pracy poświęconego na administrację zapleczem udostępniającym moc obliczeniową oraz przestrzeń na dane użytkowników, ale... W zamian otrzymują możliwość pełnej kontroli nad tym, kto i w jaki sposób korzysta z ich oprogramowania. Rynek wtórny lub piractwo? Można o nim spokojnie zapomnieć. Natomiast przy odrobinie chęci i korzystając z nieświadomości użytkowników można doprowadzić do stanu, w którym to użytkownicy zostaną uzależnieni od naszych usług. Vendor lock-in. Brzmi nierealnie? A próbowaliście kiedykolwiek dokonać migracji np. z Google Picasa do innej usługi? A co zrobicie, gdy usługodawca zwiększy ceny swoich usług? Pojawia się tutaj również wolnego i otwartego oprogramowania oraz wykorzystania otwartych standardów. Te ostatnie są szczególnie ważne w przypadku próby integracji kilku usług oraz migracji użytkowników między nimi. Jest to zazwyczaj ta funkcjonalność o której nie myśli się zbyt często przed tym, kiedy to staje się naprawdę konieczna. A co do tego ma wolne oprogramowanie? Wyobraźcie sobie teraz, iż chcielibyście samodzielnie zająć się ochroną własnych danych. Chcielibyście postawić serwer danej usługi korzystając z własnego zaplecza informatycznego i... Niestety, taka opcja nie istnieje. Co więcej, usługodawca nawet, gdy korzysta ze zmodyfikowanego oprogramowania na bazie GPL nie jest zobowiązany do tego, aby je udostępnić. Przecież nie dystrybuuje go.

To, o czym wspomniałem to jedynie szczyt góry lodowej. Można byłoby na ten temat napisać znacznie więcej, wskazać zalety SaaS oraz zaproponować rozwiązanie pewnych problemów związanych z usługami. Nie było to jednak moim celem.

Podsumowując, chciałbym zwrócić uwagę na to, iż rozwiązania oparte o zamknięte oprogramowanie oraz SaaS może i nie są złe, ale budzą pewne obawy i należy mieć do nich dystans. Owszem, pozwalają one firmom zamienić koszta stałe, jakim jest zakup oprogramowania, na koszta zmienne i posiadają szereg innych zaleta, ale... Użytkownicy powinni nie tylko myśleć o tym, co jest „tu i teraz”, ale również o przyszłości. Nikt z nas nie chciałby doprowadzić do utraty swoich danych, ich wycieku, czy też niemożności migracji do innego usługodawcy. A takie zagrożenia niesie ze sobą koncepcja SaaS, gdy korzysta się z niej bez wstępnego jej przeanalizowania.

Wstęp

Wszystko zaczęło się od wpisu, który poczyniłem tydzień temu. Zafascynowała mnie koncepcja małego, bezgłośnego, energooszczędnego i taniego komputera, który mógłby pracować w systemie 24/7 i służyć np. za domowy NAS. Terminal HP Compaq T5520 okazał się być łatwo dostępny. Poniżej znajduje się krótki opis tego, czym jest taki terminal i jakie oferuje możliwości.

Cienki klient HP między popularnym modemem kablowym Motoroli, a routerem Linksysa. Wymiary terminala T5520: około 35 x 10 x 35 centymetrów.

Między bebechami

Na zakupiony przeze mnie model składa się procesor VIA Eden ESP 8000 (rdzeń „Nehamiah” 0,13 µm taktowany 800 MHz, 133 MHz FSB, 64 KiB L2), chipset VIA CLE266, 128 MiB SODIMM (przylutowane do płyty głównej), karta Ethernet 100 Mbit, karta graficzna S3 UniChrome (przywłaszcza sobie 16 MiB z RAM-u) oraz karta muzyczna. Całość dopełniają 4 gniazda USB 2.0, port szeregowy, równoległy, PS/2, VGA, LAN oraz wejście mikrofonowe i wyjście słuchawkowe. Mnie interesowały głównie porty USB, bo i tak większość z pozostałych zostałaby użyta jedynie podczas instalacji systemu operacyjnego. W tym momencie warto od razu odpowiedzieć na pytanie, gdzie taki system można umieścić. Całość dostarczana jest z 64 MB pamięci flash (zawiera ona system Windows CE 5.0) podpiętej przez 2,5" złącze ATA do płyty głównej. Jak łatwo się domyślić, jedną z atrakcji jest możliwość wymienienia jej na 2,5'' dysk twardy z interfejsem ATA - jedyne o czym należy pamiętać to zdobycie odpowiedniej tasiemki IDE (złącza żeńskie-żeńskie). Warto jeszcze wspomnieć, że o ile sam CPU na płycie głównej nie jest zbyt wydajny to całkiem nieźle sprawdza się w przypadku szyfrowania danych cipherem AES ze względu na sprzętowe wsparcie szyfrowania symetrycznego (tzw. VIA Padlock). Przejdźmy teraz do samej kwestii instalacji właściwego systemu operacyjnego.

Instalacja GNU/Linuksa

Pierwsze, co zrobiłem po otrzymaniu sprzętu to jego rozkręcenie oraz wyjęcie na kilka sekund baterii z płyty głównej zasilającej CMOS. W przypadku, gdyby ekran konfiguracji BIOS-u był zabezpieczony hasłem pozwoliłoby mi to na zaoszczędzenie czasu poprzez wcześniejsze usunięcie go w ten sposób. Przy okazji przyjrzałem się wnętrzu urządzenia i sprawdziłem, czy wszystkie kondensatory są w normie. Po złożeniu i podłączeniu peryferiów uruchomiłem terminal trzymając podczas startu klawisz F9 aż do momentu, gdy usłyszałem dźwięk z wbudowanego głośniczka. To oznaczało, że konfiguracja Windowsa CE powróciła do ustawień fabrycznych i będę mógł się z nim nieco pobawić. Zapewniam jednak, że 5 minut w zupełności na to wystarcza. Później pozostało jedynie przejść do konfiguracji BIOS-u i ustawić odpowiednią kolejność bootowania. W moim przypadku koncepcja była prosta.

Nie miałem zamiaru bawić się zbyt długo, dlatego uznałem, że skorzystam z Ubuntu 9.10 Server Edition dostępnego na płycie CD oraz mojego napędu DVD znajdującego się w kieszeni z interfejsem USB. Wbudowany w terminal dysk flash miał posłużyć jako miejsce składowe dla jądra (/boot) oraz GRUB-a, a podpięty przeze mnie 4 GB dysk jako miejsce dla całej reszty systemu (/ oraz swap). Jak pomyślałem tak też zrobiłem. W trakcie instalacji zaliczyłem „freeze”, więc szybko zmieniłem początkowe założenia. Ubuntu zostało wyparte przez Debiana „Lenny” 5.04 w wersji „network install”. I to była właściwa decyzja. Debian kolejny raz uratował mi odwłok. Po długotrwałej instalacji (30 minut? 60?) dorzuciłem jeszcze na pokład serwer SSH i wyłączyłem system. To był czas na przejście w „tryb bezgłowy” i zarządzanie z poziomu innego komputera. Kilka wpisów w domowym DNS-ie i Thor (mitologia nordycka rządzi) był gotowy do działania.

Serwer SSH to nie wszystko. Docelowo terminal ten ma służyć do kilku celów, które spełniać mają serwery: NTP, CUPS, NFS, Samba, czy też webowy interfejs Transmission (klient BitTorrenta). Wszystkie dane, które nie są systemem operacyjnym i jego plikami konfiguracyjnymi muszą być również szyfrowane AES-em. Oznacza to m.in. wykorzystanie dysku 2.5" w kieszeni USB oraz DM-Crypta, który do najmniej zasobożernych rozwiązań nie należy. A jak wygląda kwestia zasobów po czystej instalacji systemu? Brak obciążenia procesora, około 16 MiB pamięci (z pominięciem buforów) pożartej przez system i podstawowe usługi oraz niewielka konsumpcja przestrzeni dyskowej. Jest to indywidualna sprawa, ale warto o niej wspomnieć. System wstaje około minuty licząc od zerwania połączenia SSH po wydaniu polecenia reboot do momentu, kiedy możliwe jest ponowne zalogowanie poprzez SSH. Czas na prawdziwą pracę! Tj. zaraz po upgrade do obecnego wydania testing Debiana, czyli przyszłego „Squeeze”.

Wydajność

To, co miało być głównym przeznaczeniem tego miniserwera to przede wszystkim dostęp do zaszyfrowanego (DM-Crypt, LUKS i cipher AES) dysku z wykorzystaniem NFS. Zacznijmy zatem od samego szyfrowania oraz od tego, jak sprawdza się terminal w takich zastosowaniach. Do testów wykorzystałem polecenie hdparm -t. Na początku zastosowałem to polecenie kilkukrotnie na dysku, który nie został poddany szyfrowaniu:

zal@thor:/media$ sudo hdparm -t /dev/sdb

/dev/sdb:
 Timing buffered disk reads:   94 MB in  3.01 seconds =  31.23 MB/sec

Całkiem niezły wynik, najprawdopodobniej maksymalny możliwy do uzyskania transfer w przypadku wykorzystania USB 2.0. Następnie wykonałem standardowe polecenia cryptsetup mające na celu stworzenie utworzenie i zmapowanie zaszyfrowanej partycji po czym wykonałem na niej test z hdparm. Rezultat jest mało zadowalający:

zal@thor:/media$ sudo hdparm -t /dev/mapper/XXX

/dev/mapper/XXX:
 Timing buffered disk reads:   22 MB in  3.28 seconds =   6.70 MB/sec

A teraz najważniejsze. Ponowiłem ww. operację ładując wcześniej do pamięci moduł padlock-aes dzięki któremu możliwe jest wykorzystanie wsparcia sprzętowego (procesor z rozwiązaniem VIA Padlock) dla szyfrowania przy pomocy ciphera AES. Oto i rezultat:

zal@thor:/media$ sudo hdparm -t /dev/mapper/XXX

/dev/mapper/XXX:
 Timing buffered disk reads:   62 MB in  3.02 seconds =  20.51 MB/sec

Wygląda to zdecydowanie lepiej. Niestety, nie byłem w stanie określić obciążenia procesora w tym momencie. Wygląda jednak na to, że nawet na takim sprzęcie szyfrowanie całego dysku może mieć sens.

Reszta testów (m.in. dot. obciążenia procesora podczas przesyłu danych oraz prędkości przesyłania danych) będzie miała sens dopiero, gdy złożę odpowiednie środowisko testowe. W obecnej chwili uważam, że zbyt duży wpływ na wynik takich badań może mieć router (działający w oparciu o DD-WRT) pośredniczący w przepływie danych oraz kwestia tego, że jeden z komputerów przesyła dane za pośrednictwem sieci bezprzewodowej. Gdyby jednak ktoś chciał przeczytać to, co uzyskałem korzystając z ww. środowiska może to zrobić zaglądając w kod XHTML niniejszego wpisu i szukając najdłuższego komentarza w nim zawartego. Wskazówka, znajduje się on pod niniejszym paragrafem.

Podsumowanie

Niniejszy wpis powstał zaledwie w ciągu kilku godzin od momentu uruchomienia przeze mnie opisywanego terminala. Pomimo tego, że sprzętem jestem zachwycony to należy mieć na uwadze to, że tak krótki okres jest niewystarczający do tego by móc polecić tego cienkiego klienta komukolwiek. Dopiero po miesiącu, czy też dwóch, użytkowania mogą wyjść na jaw jego największe wady, jak i zalety. Obecnie uważam, że sprzęt ten ma naprawdę duży potencjał i może stanowić konkurencję dla samodzielnie składanych, domowych NAS-ów opartych o stare podzespoły. Nie jest demonem prędkości, ale jest tani, cichy i energooszczędny.

Ciąg dalszy zapewne nastąpi w bliżej nieokreślonej przyszłości. Mam zamiar wykonać bardziej precyzyjne i wiarygodne testy dot. wydajności.

Jako, iż ostatnio zrobiło się głośno o projekcie Tor, a w repozytorium Ubuntu znaleźć go nie można (jedynie GNUnet trafił do repo) poniżej znajduje się krótka informacja dot. tego, jak uruchomić Tora i powiązać go z Privoxy pod Ubuntu 9.10.

Można to uczynić w dwojaki sposób. Pierwszym z nich jest samodzielna kompilacja Tora ze źródeł. Drugi, który zostanie przeze mnie opisany, wymaga skorzystania ze skompilowanej już wersji Tora z repozytorium twórców projektu. Wystarczy dodać do /etc/apt/sources.list poniższą linię:

deb http://deb.torproject.org/torproject.org karmic main

Później należy wydać polecenia, które pozwolą na instalację Tora i Privoxy z dodanego przed chwilą repozytorium:

gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
sudo aptitude update
sudo aptitude install privoxy tor tor-geoipdb torbutton-extension

Od teraz Tor oraz Privoxy będą usługami uruchamianymi wraz ze startem systemu, co można sprawdzić obserwując zawartość katalogu /etc/rc2.d/. Kolejnym krokiem jest wykorzystanie naszego ulubionego edytora w celu otwarcia /etc/privoxy/config (należy pamiętać o uprawnieniach administratora) i dodania na sam koniec pliku następującej linii (kropka na końcu jest ważna):

forward-socks4a / localhost:9050 .

Od teraz Privoxy będzie wykorzystywał Tora do komunikowania się ze światem zewnętrznym. Na sam koniec wystarczy jeszcze włączyć w przeglądarce opcję korzystania z proxy HTTP o następującej lokalizacji - adres localhost, port 8118. W przypadku Firefoksa polecam instalację Torbutton do szybkiej zmiany ww. ustawień oraz w celu zapewnienia wyższej anonimowości. Poprawność działania całości można sprawdzić odwiedzając stronę wykrywającą połączenia wykonywane za pośrednictwem Tora.

Połączenie Tora z Privoxy sprawdza się tam, gdzie zależy nam na zachowaniu resztek anonimowości. Na przykład podczas zostawiania komentarzy na blogach z polskiej platformy blogowej Blox. Należy jednak mieć świadomość tego, że nie jest to rozwiązanie idealne i może się nie sprawdzać w przypadku, gdy komuś naprawdę zależy na odkryciu naszej tożsamości. Co więcej, zachowanie anonimowości zależy również od kilku innych czynników takich, jak np. włączona obsługa JavaScriptu w przeglądarce, ciasteczek itp.

Podstawowa konfiguracja Tora umożliwia nam korzystanie z sieci utworzonej z funkcjonujących już przekaźników, ale nie powoduje dołączenia do niej jako kolejny przekaźnik. Oznacza to, że tylko użytkownicy naszego komputera są w stanie wykorzystywać go w roli bramy do anonimowego Internetu. Do konfiguracji Tora można wykorzystać aplikację Vidalia posiadającą graficzny interfejs, lub skorzystać z edytora tekstowego i pliku konfiguracyjnego.

Urządzenia zgodne z grupą standardów 802.11 stają się coraz popularniejsze. O ile kiedyś stanowiły rzadkość, tak teraz zarówno bezprzewodowe karty sieciowe w komputerach, jak i routery bezprzewodowe na biurkach, to standard. To, co mnie jednak zaczęło interesować to sposób, w jaki realizowany jest w nich przesyłanie danych. Scentralizowany tryb infrastruktury oraz zdecentralizowany, oparty na dynamicznym routingu, tryb „ad hoc”. Moje pytanie jest stosunkowo proste - dlaczego współczesne routery bezprzewodowe na rynek SOHO oferują zazwyczaj jedynie tryb infrastruktury? Pytanie szczególnie interesujące, gdy przeanalizuje się wady i zalety trybów „ad hoc” oraz „infrastructure”.

Przykład sieci Wi-Fi opartej o tryb infrastruktury. Komunikacja między klientem 1 i 2 zachodzi za pośrednictwem Access Pointa. Jeden z klientów nie może się komunikować z siecią - jest poza zasięgiem AP (pomimo obecności w zasięgu innych klientów).

Należy zauważyć, że w najprostszym przypadku sieci bezprzewodowej z wykorzystaniem trybu infrastruktury tworzona jest sieć o topologii gwiazdy. Rozwiązanie to, jak każde inne, ma swoje wady i zalety. Zacznijmy od zalet:

• łatwa kontrola dostępu do sieci (np. WPA2-Enterprise),
• ustalone punkty dostępu do sieci,
• przewidywalny zasięg sieci,
• niski koszt routingu (nawet w przypadku zastosowania roamingu),
• niskie zapotrzebowanie na energię oraz moc obliczeniową klientów sieci.

Wszystkie te trzy punkty sprawdzają się w rzeczywistości, o ile w sieci nie pojawi się agresor. Załóżmy jednak, że niewątpliwą zaletą takiej sieci jest właśnie jej ustalona struktura umożliwiająca stosunkowo łatwe zarządzanie nią. A wady?

• wysoki koszt budowy,
• niewielki zasięg sieci (ograniczony elementami architektury),
• ograniczona przepustowość w przypadku połączeń peer-to-peer,
• zawodność.

Scentralizowany charakter sprawia, że funkcjonowanie takiej sieci jest ściśle związane z prawidłową pracą elementów jej architektury. W przypadku sieci złożonej z jednego AP, jego awaria oznacza awarię całej sieci. Problemem jest również jej wąskie gardło, które objawia się w dwojaki sposób. Po pierwsze, zasięg takiej sieci jest ograniczony przez umiejscowienie elementów architektury. Po drugie, podczas komunikacji między użytkownikami sieci wszystkie dane są przesyłane za pośrednictwem AP. Oznacza to, iż w przypadku jednoczesnej wymiany danych przez kilku użytkowników, prędkość przesyłania może drastycznie spać.

Przykład sieci Wi-Fi opartej o tryb „ad hoc”. Klienci 1 i 2 mogą się ze sobą komunikować pomimo tego, iż są poza zasięgami swoich anten. AP jest tutaj nazwany umownie - jest to urządzenie, które dostarcza takie usługi, jak np. dostęp do Internetu.

Przyjrzyjmy się teraz sieciom tworzonym „ad hoc”. Ich niewątpliwymi zaletami są:

• niski koszt budowy,
• zasięg sieci zależny od liczby i rozmieszczenia jej członków,
• wysoka prędkość komunikacji między sąsiadującymi ze sobą klientami,
• odporność na awarie.

Zdecentralizowany charakter ww. trybu sprawia, że jest to sieć idealna do zestawiania jej tam, gdzie nie ma elementów infrastruktury. Każdy jej element jest równie ważny i każdy zajmuje się przesyłaniem danych do innych (dynamiczny routing). Dzięki temu pozbywamy się wąskiego gardła jakim są elementy infrastruktury oraz zyskujemy wyższą niezawodność jej działania. Z łatwością można wyobrazić sobie linię złożoną z klientów sieci, w której to osoby znajdujące się na skrajnych jej brzegach nadal są w stanie się ze sobą komunikować. Niestety, takie rozwiązanie ma swoje wady:

• trudność w ograniczeniu dostępu do sieci,
• brak możliwości zastosowania rozwiązań pokroju WPA2-Enterprise,
• narzut związany z działaniem algorytmu routingu dynamicznego,
• wyższe zapotrzebowanie na moc obliczeniową i energię członków sieci.

Jak widać powyżej, wady sieci „ad hoc” najprawdopodobniej uniemożliwiają stosowania jej w większych organizacjach (np. przedsiębiorstwach posiadających kilkunastu pracowników). A już z pewnością nie jako sieci o stałym charakterze. A co z domami i małymi firmami?

Uważam, że w przypadku małych sieci, których zabezpieczenie oparte jest o WPA, lub WPA2 Personal i filtrowanie MAC-ów, dobrym rozwiązaniem byłoby zastosowanie routera bezprzewodowego pracującego w trybie „ad hoc”. Patrząc z punktu widzenia udostępnianej funkcjonalności i tak byłby on elementem nadrzędnym sieci (DNS, DHCP, dostęp do Internetu itp.), ale dzięki wykorzystaniu „ad hoc” byłyby możliwym poszerzenie zasięgu sieci oraz zwiększenie wydajności komunikacji między jej klientami (w sprzyjających warunkach).

Co ciekawe, nie widziałem na rynku routerów, które umożliwiałyby pracę w trybie innym, niż „infrastructure”. Sugerowane przeze mnie rozwiązanie jest jednak możliwe do realizacji przy pomocy bezprzewodowego routera pracującego w oparciu o oprogramowanie DD-WRT. W najbliższym czasie mam zamiar przetestować moją koncepcję. Nim jednak to się stanie oczekuję na Wasze komentarze i sugestie. Możliwym jest, iż moja niewiedza z zakresu funkcjonowania sieci bezprzewodowych sprawiła, że wysnułem nieprawidłowe wnioski.

Czy praca w trybie „ad hoc” może być dobrym rozwiązaniem w przypadku routerów przeznaczonych na rynek SOHO?

Collect. Process. Organize. Review. Do.

O metodzie Getting Things Done pisało już wielu. Również i ja nie będę tego robić pierwszy raz. W telegraficznym skrócie - GTD jest metodą organizacji czasu, której celem jest odciążenie naszej pamięci przy jednoczesnym zachowaniu wysokiej efektywności. W artykule na Wikipedii znajduje się opis tego, z jakich procesów się ona składa. Co ciekawe, jej wdrożenie nie wymaga żadnego urządzenia elektronicznego, ale trzeba przyznać, iż wykorzystanie właściwego oprogramowania zdecydowanie ułatwia korzystanie z niej. Z tego też względu poniżej znajduje się krótki opis mojej przygody z wdrażaniem GTD w życie oraz aplikacji (w świecie Linuksa), która okazała się być rozwiązaniem bliskim ideałowi.

Historia zaczęła się od zabawy z moim ulubionym edytorem tekstu, czyli Emacsem oraz dodatkiem Org-mode. Org-mode jest godny polecenia - świetnie nadaje się do tego, do czego został stworzony. Pomimo wysokiego początkowego kosztu związanego z nauką jego obsługi warto się nim zainteresować z tego względu, iż minimalizuje późniejszy koszt (czas to pieniądz) np. tworzenia notatek. Pod tym względem jest podobny do LaTeX-a, którego nauka również potrafi na początku odstraszyć osoby przyzwyczajone do Microsoft Worda, lub OpenOffice.org Writera. Nie zmienia to jednak faktu, że przystosowanie Org-mode do GTD jest pracochłonne i do tego akurat zadania nie nadaje się on najlepiej. Zależy nam przecież na wydajnym działaniu, a nie na przyjemności wynikającej z samej możliwości zarządzania czasem.

Kolejnym moim krokiem były poszukiwania czegoś, co przypominałoby systemy typu Wiki. Jak się okazuje, dużą popularność pośród zwolenników takich rozwiązań zyskały modyfikacje TiddlyWiki, czyli Wiki mieszczącej się w pojedynczym pliku będącym połączeniem HTML-a, JavaScriptu oraz danych użytkownika. Ma to taką zaletę, że jest to rozwiązanie zupełnie niezależne od systemu operacyjnego. Wystarczy jedynie posiadać przeglądarkę WWW. Natomiast synchronizację między wieloma komputerami można uzyskać korzystając np. z DropBoksa, Ubuntu One, lub serwisu TiddlySpot. Samo TiddlyWiki może służyć do GTD, ale lepiej skorzystać z czegoś, co zostało stworzone do współpracy z tą metodą, a bazuje na wspomnianym systemie Wiki. Mowa m.in. o MonkeyGTD. Całość nie przypadła mi jednak do gustu - narzędzia tego typu są stosunkowo trudne w obsłudze i mało przejrzyste. A przecież nie tego oczekuje się od rozwiązania, które samo w sobie ma ułatwiać życie.

Przez chwilę zastanawiałem się również nad zastosowaniem ThinkingRock. Szybko jednak uznałem, że pomimo dużej sympatii do Javy niekoniecznie chcę korzystać z takiego molocha przy zabawach z organizacją mojego czasu. Nie wspominając o tym, iż przejrzystością ThinkingRock przypomina raczej węgiel, niźli diament.

I tutaj pojawiła się myśl - może jakaś aplikacja webowa? Najlepiej coś należącego do świata FLOSS, ale na tyle popularnego, aby można było znaleźć darmowy serwis udostępniający ją jako SaaS. Remember the Milk odpadał w przedbiegach ze względu na kryterium wolności oprogramowania. Okazało się jednak, że warunki te spełnił tytułowy Tracks (Ruby on Rails) oraz portal GTDify (można też skorzystać z Tracks.tra.in). I w tym oto momencie doszedłem do rozwiązania, z którego korzystam od jakiegoś już czasu i chwalę je sobie.

Otwarta (GPL), prosta w obsłudze i, co najważniejsze, praktyczna aplikacja. Do każdego miejsca można dostać się przy pomocy maksymalnie trzech kliknięć. Co więcej, posiada wsparcie wsparcie nie tylko dla kontekstów oraz projektów, ale również tagów. Jedno spojrzenie wystarcza do tego, aby szybko stwierdzić, co i na kiedy należy zrealizować, a dodawanie zadań jest przede wszystkim szybkie. Gdyby przeglądarka WWW nie wystarczała to zawsze istnieje możliwość skorzystania z różnego rodzaju feedów XML, iCal, lub tekstowych. Istnieje również możliwość eksportu danych (chociaż z importem jest już nieco gorzej).

Dobrze wdrożony GTD naprawdę ułatwia życie.

Tak, jak ostatnio wspominałem, zabrałem się za napisanie prostego narzędzia do migracji z Joggera (wymagany plik XML z eksportem) do WordPressa (wymagany dostęp do bazy danych) w wersji 2.8.*. JoggerLaunch, bo o nim mowa, pozwala obecnie na przeniesienie do WP wszystkich swoich wpisów oraz komentarzy do nich. Niestety, nie obsługuje jeszcze przenoszenia tagów oraz kategorii do jakich należały wpisy. Funkcjonalność ta z pewnością niedługo się pojawi.

Do napisania skryptu wykorzystałem Rubiego. Powodem, dla którego wybrałem ten język jest fakt tego, iż nigdy wcześniej nie miałem z nim do czynienia. Bo czemu nie? Kod wygląda upiornie, ale przetestowałem go na ponad 5 mebibajtowym XML-u i daje poprawne rezultaty.

Gdyby ktoś miał ochotę dorzucić do niego funkcjonalność, lub poprawić kod i efektywność działania to gorąco zapraszam - jest na licencji BSD.

Na obecną chwilę istnieje naprawdę dużo rozwiązań pozwalających na szyfrowanie danych. Wystarczy wspomnieć chociażby o TrueCrypt, DM-Crypt+LUKS, OpenGPG itp. Wszystkie one opierają się mniej, lub bardziej popularnych algorytmach kryptografii symetrycznej (np. AES) i asymetrycznej (np. RSA). I wszystkie one są naprawdę dobre do momentu, kiedy to okazuje się, że nie mamy dostępu do komputera. Co zrobić, gdy mamy dostęp jedynie do kartki i ołówka?

Dlaczego w ogóle o tym piszę? Przykładowa sytuacja z życia wzięta. Marta znajduje się w Ekwadorze. Ja zaś jestem tam, gdzie zawsze byłem, czyli w Polsce. Z różnych powodów Marta nie posiada przy sobie zarówno komputera, jak i telefonu komórkowego. Jedyny działający telefon w okolicy należy do koleżanki Marty i bez problemu może służyć do odbierania SMS-ów. Chcąc jednak zachować prywatność, przesyłany tekst należałoby w jakiś sposób zaszyfrować. Szyfry wykorzystujące XOR-y oraz bardziej zaawansowane operacje arytmetyczne są zbyt skomplikowane przy szyfrowaniu/deszyfrowaniu wykonywanym przez człowieka. Zatem jaki szyfr wykorzystać?

Założenie jest proste - szyfr musi być prosty do stosowania i w miarę bezpieczny, czyli wymagający uwagi osoby obeznanej w temacie by zostać złamanym. Szyfry przestawieniowe oraz tradycyjny ROT13 odpadają już na samym wstępie, ale można wykorzystać m.in. szyfry podstawieniowe. Przeszukałem Internet pod kątem klasycznych metod szyfrowania i wybrałem najbardziej interesujące w moim mniemaniu rozwiązania. Oto i one:

• wariacja szyfru Vigenère'a z kluczem jednorazowym,
• wariacja szyfru Vigenère'a z autokluczem,
• szyfr Ottendorfa.

Każdy z wyżej wymienionych szyfrów ma swoje wady. Pierwszy wymaga tego, aby po obu stronach uczestniczących w komunikacji pojawiła się książka z identycznym ciągiem losowych znaków, która będzie pełnić rolę klucza jednorazowego. Dodatkowo potrzebna jest „tabula recta” (widoczna powyżej). Jednakże można ją samodzielnie wygenerować w ciągu 2-3 minut. Efekt? Szyfr, do którego złamania należy zdobyć wspomniany klucz. Bez niego uzyskanie tekstu jawnego jest niemożliwe. Przy okazji jest on też bardzo niewygodny w stosowaniu. Odpada.

Wersja z autokluczem wygląda na znacznie bardziej interesującą. Po pierwsze - wymaga jedynie wspomnianej już tabeli ze wszystkimi możliwymi przesunięcia alfabetu. Po drugie - szyfrowanie/deszyfrowanie jest stosunkowo proste, a próba odczytania bez znajomości pierwszych kilku znaków klucza wymaga nieco czasu i pewnej wiedzy. Wady? Jego złamanie jest tylko kwestią czasu.

Co do ostatniego szyfru to jest on interesujący chociażby z tego względu, iż kluczem jest w tym przypadku książka. Każdą literę tekstu jawnego przekształca się do postaci XXYYZZ, gdzie XX to numer strony danej książki, YY to wiersz na danej stronie, a ZZ to kolejny znak będący znakiem z tekstu jawnego. Niestety, szyfrowanie/deszyfrowanie jest długotrwałe, a powstały w ten sposób kryptogram jest kilka razy dłuższy od tekstu jawnego. Przy okazji jest mniej bezpieczny, niż szyfr Vigenère'a z kluczem jednorazowym.

Decyzja zapadła. Ze względu na komfort stosowania oraz stosunkowo wysoki stopień bezpieczeństwa wybrałem szyfr z automatycznym generowaniem klucza. Jak zatem szyfrować z jego wykorzystaniem? To proste, spójrzcie na przykład.

JAWNY: zaszyfrowanyxtekst
KLUCZ: haslozaszyfrowanyt
KRYPT: 

Jak widać, klucz tworzony jest poprzez umieszczenie na jego początku nieznanej nikomu frazy (np. haslo) oraz tekstu jawnego, który będzie szyfrowany. Teraz należy przystąpić do szyfrowania - będzie nam potrzebna wcześniej wspomniana „tabula recta”. Odnajdujemy w niej kolumnę „z” oraz wiersz „h” (lub na odwrót, nie ma to znaczenia) i do kryptogramu wpisujemy literę leżącą na ich przecięciu, czyli „g”. Dla „a” i „a” będzie to „a” itd. Otrzymamy następujący wynik.

JAWNY: zaszyfrowanyxtekst
KLUCZ: haslozaszyfrowanyt
KRYPT: gakkmergvysplpexqm

Proste, prawda? Deszyfrowanie kryptogramu polega na odnalezieniu kolumny, lub wiersza oznaczonego literą z klucza, a następnie w danej kolumnie/wierszu odnajdujemy literę z kryptogramu. Litera tekstu jawnego to litera oznaczająca wiersz w przypadku, gdy na początku wybraliśmy kolumnę, lub oznaczająca kolumnę, gdy wybraliśmy na początku wiersz, w którym znajduje się odnaleziona litera. Na początku klucz nie jest w pełni znany, aby go wygenerować osoba deszyfrująca kryptogram musi znać jedynie wspomnianą wcześniej frazę (np. haslo) i umieszczać w kluczu kolejne litery odszyfrowanego tekstu jawnego.

Proste, łatwe i prawie przyjemne. Trzeba mieć jedynie świadomość tego, iż jest to szyfr podatny na złamanie. M.in. w przypadku długich tekstów, krótkich fraz początkowych oraz stosowania tej samej frazy początkowej do szyfrowania większej liczby wiadomości. Warto zapoznać się z informacjami zawartymi na Wiki oraz z narzędziem do jego łamania.

Szukałem prostego i lekkiego odtwarzacza o dużych możliwościach. Na stabilną i w pełni funkcjonalną wersję fooaudio zarówno wtedy, jak i teraz, trzeba było jeszcze poczekać. Aż w pewnym momencie pojawił się pomysł, aby zastosować najprostsze ze wszystkich rozwiązań - MPD.

MPD jest znany chyba każdemu użytkownikowi Linuksa z kilkuletnim stażem. Jest to mały i elastyczny odtwarzacz muzyczny działający w formie daemona. Idealny do pracy bez X-ów, czy też jako dodatek do minimalistycznych środowisk graficznych - zajmuje zaledwie około 8 mebibajtów w RAM-ie. Komendy można mu przesyłać bezpośrednio na gniazdko (np. dzięki programowi netcat), na którym nasłuchuje, lub korzystając z prostych nakładek graficznych. Z tych mniej zasobożernych warto wymienić pracującego pod konsolą ncmpc++ (2 MiB w pamięci).

Instalacja zarówno samego odtwarzacza, jak i interfejsu jest prosta, jak budowa cepa. Następnie wystarczy dodać odpowiednie symlinki odnoszące się do folderów z muzyką (aby nie grzebać się z plikiem konfiguracyjnym), zmienić prawa dostępu do własnego zbioru muzycznego oraz wykonać aktualizację bazy MPD. Voilà!

Proste, łatwe i przyjemne. A do tego ile możliwości.