Globalne ocieplenie czyli public review.

W temacie globalnego ocieplenia znowu zrobiło się gorąco. Ostanie trzy dni przyniosły aż trzy newsy. Chronologicznie środkowy to głos sceptyków i tradycyjne obecne modele ocieplenia klimatu są złe, to nie jest takie straszne. Na co, jako ostatni news, oczywiście pojawiły się odpowiedzi typu modele są dobre, próba obalenia jest zła.

Pojawiać się może pytanie, skąd takie rozbieżności u naukowców, którzy operują na obiektywnych danych? Wiadomo, że klimat rozmów o klimacie nie jest najlepszy. Nie chodzi o przyczynę (jak nie wiadomo o co chodzi, to chodzi o…, chociaż zwykła niemożność przyznania się, że ileś tam lat pracy powinno trafić do kosza też wchodzi w grę), tylko o jak to jest, że biorą to samo i mają przeciwne wyniki? No właśnie… nie biorą tego samego.

Po pierwsze, nie wszyscy mają dostęp do tych samych danych. Publikacja przez Wikileaks danych, modeli i emaili dotyczących badań nad globalnym ociepleniem pokazała, jak naukowcy z grupy „proociepleniowej” opracowujący modele starają się utrudnić „reszcie świata” dostęp do danych i modeli (odmowa publikacji, obscufowanie).

Po drugie, dane „nie pasujące do modelu” są pomijane. Przez obie strony, gwoli ścisłości. Pozostaje pytanie o kryteria odrzucenia danych – statystyka i prognozowanie jak najbardziej dopuszcza coś takiego, ale przy odrobinie złej woli lub zwykłym błędzie w prosty sposób pozwala to też wypaczyć wyniki.

Po trzecie, są różne metody budowania modeli. Oczywiście każda daje trochę inne rezultaty. I zakłada pominięcie innych danych, więc jest naturalne, że wyniki będą się różnić, pozostaje pytanie jak bardzo.

O rozbieżności czy błędy w obliczeniach, nawet tych stosunkowo prostych, nie jest trudno. Nawet wtedy, gdy liczy się proste sprawy, takie jak np. ile tak naprawdę płacimy podatku od przychodu z wykonanej pracy (wpis na ten temat niebawem, sprawa ciekawa bo wahania były od 83%, przez 70% do ok. 50%). Dlatego jestem zwolennikiem publikowania pełnych danych, zarówno źródłowych, jak i dotyczących modelu obliczeń. Jest szansa, że ktoś przejrzy i znajdzie błędy, nieścisłości, nieuwzględnione dane i model będzie lepszy. Tworzenie sekretów i knucie prowadzi do podejrzliwości i teorii spiskowych, zaczyna się kombinowanie, FUD i propaganda zamiast nauki. Co nie dziwi, biorąc pod uwagę, że na wynikach tych badań opierają się decyzje w zakresie prawa i polityki. Ale IMHO nauka powinna być ponad tym.

I na koniec pierwszy chronologicznie news – po latach starań „sceptyków klimatycznych” zostały opublikowane dane z większości stacji na świecie. Polska jak zwykle się popisała i odmówiła zgody na publikację danych (ciekawe czemu, bo mam wrażenie, że zostały on uzyskane za pomocą środków publicznych). Czyli teraz każdy może spróbować zbudować swój model zmian klimatu, albo po prostu sprawdzić, czy naukowcy nie zrobili gdzieś błędu (o ile opublikują swój model, tj. algorytm/funkcję z której korzystają). Małe, a cieszy.

Pomiary Internetu – RIPE Atlas probe.

Jakiś czas temu pisałem o pomyśle MI na minimalną prędkość Internetu. Niedawno sonda z projektu RIPE Atlas dotarła i została uruchomiona, wydaje mi się, że to dobry pomysł, żeby wrócić do tematu, bo jest parę analogii.

Sama sonda to prosty komputer, wielkości mniej więcej pudełka zapałek (określenie „beczułka” do łączenia kabli ethernetowych jest bliższe, ale pewnie większość ludzi nie będzie wiedziała o co chodzi), zasilany przez USB, z gniazdem na wtyczkę sieciową. Otrzymać go (za darmo, zarówno sprzęt – który pozostaje własnością RIPE, jak i wysyłka) może teoretycznie każdy, ale póki co chyba głównie do ISP wysyłają. I tego szpiega trzeba umieścić w sieci, z dostępem do Internetu, żeby robił pomiary.

W zamian dostajemy dostęp do danych (wykresy) zebranych przez naszą sondę, co może pomóc w monitorowaniu sieci (nic, czego nie dałoby się zrobić samodzielnie, ale jest ładny gotowiec). W chwili obecnej mierzone są głównie opóźnienia od „ważniejszych miejsc” w Internecie. Poza tym, właściciel może oznaczyć sondę jako publiczną i wtedy każdy, kto założy konto, będzie mógł oglądać jej wykresy. Publicznych sond całkiem sporo, jeśli ktoś ma nadmiar czasu to może sobie pooglądać.

Analogii z pomysłem MI jest sporo – są pomiary, jest „niezależny” sprzęt (cudzysłów, bo wiadomo, że wyniki z centralnego punktu sieci nijak muszą się mieć do tego, co dostanie Kowalski, kreatywny QoS też jest możliwy…). Ładnie widać, jakie są koszta (kupno i wysłanie sond, system do zbierania danych), widać, jakie są efekty („obiektywny” pomiar). Nie jestem przekonany, czy Kowalski będzie w stanie wyciągnąć jakiekolwiek sensowne wnioski z danych prezentowanych przez sondę.

Faktem jest, że w chwili obecnej sonda mierzy głównie dostępność sondy i opóźnienia do określonych hostów w sieci, nie przepływności (docelowo będzie prawdopodobnie mierzyć jedno i drugie, w panelu jest opcja – obecnie nieużywana – pozwalająca na określenie przydzielonego pasma), ale chodzi o sensowność interpretacji wyników – dla kogo istotne są opóźnienia do USA czy Japonii? Jasne, można zebrać wyniki, jakoś uśrednić i zrobić ranking, ale… Do obiektywnego pomiaru jakości sieci u Kowalskiego, który chciało zrobić MI nadal bardzo daleko.

Przeniesienie numeru z PlusGSM do Play.

O tym, że przeniosę numeru z Plusa odgrażałem się już dawno. Co prawda niechciane SMSy z reklamami w Plusie udało się wyłączyć bez problemu, a do reszty jakoś się przyzwyczaiłem, ale idea pozostała. Po prostu Plus wypada coraz gorzej na tle konkurencji. Koniec końców, póki co, nie przeniosłem numeru podstawowego tylko spam, czyli numer, który podaję wszędzie, gdzie trzeba podać telefon i jest ryzyko, że będą marketingować bez umiaru, ale… zobaczymy.

Wybór padł na Play i ich bezkonkurencyjny(?) okres ważności połączeń wychodzących po dowolnym doładowaniu, wynoszący rok. Spam to taki numer, na który głównie przyjmuję połączenia (bardziej: SMSy), więc nie było sensu płacić 200 zł/rok w Plusie (100 zł na pół roku to minimum pozwalające na wykonywanie połączeń wychodzących). Czemu nie Play od razu? Starter w Plusie kupiłem tylko ze względu na simlocka w ówczesnym telefonie…

Najlepszym dowodem, że przepłacałem, była ilość pieniędzy zebranych na koncie. Kilkanaście dni przed końcem okresu ważności połączeń wychodzących miałem tam około 150 zł. Tu drobny lifehack – część pieniędzy (około 33%) można odzyskać w gotówce na konto przy pomocy serwisu Korzystny SMS (uwaga, nie dla wszystkich sieci działa, polecam doczytanie informacji na stronie!). Linkuję, bo znalazłem go z trudem, a problem co zrobić ze środkami na koncie prepaid jest dość częsty. Konkursy – nie działa – zwykle trzeba kupić produkt i wysłać SMS albo do wygrania są drobiazgi. Darowizny – nie znalazłem niczego, co chciałbym poprzeć i co oferowałoby płatność SMS. Z innych metod wykorzystania pieniędzy na koncie prepaid – jest jeszcze zakup usług typu Skype, serwisy z pobieraniem plików wróżki i sex telefony. Jakoś nie byłem zainteresowany.

W każdym razie – przeniosłem. Słyszałem, że operatorzy robią problemy z rejestracją numeru. W moim przypadku – zupełna nieprawda. Dało się zarejestrować numer w salonie Plusa w sobotę, bez żadnych problemów, szybko, sprawnie i w miłej atmosferze.

Play reklamuje, że przeniesienie jest w jeden dzień. Trochę nie wierzyłem, bo kołatały się po głowie dwa tygodnie. Wizyta w punkcie Play i dowiedziałem się, że nie ma znaczenia, ile czasu pozostało do końca ważności doładowania (czy robiłem na ostatnią chwilę? ależ oczywiście) i że faktycznie przenoszą w jeden dzień. W niedzielę (w końcu nie było kolejki – niestety, wcześniej zawsze były 2-3 osoby w kolejce, a jakoś nie chciało mi się czekać) złożyłem dyspozycję przeniesienia. W poniedziałek numer był Play, dokładnie tak, jak powiedziano w instrukcji.

Totalnie nie mam się do czego przyczepić. Jedyne co, to mogłoby nie być fizycznej wymiany karty SIM i wypełniania sporej ilości papieru (ekologia), ale zapewne decydują odpowiednio względy technologiczne i formalno-prawne.

Moim zdaniem, na tym przykładzie, przenoszenie jest totalnie bezproblemowe. Najbardziej problematyczne jest dwukrotne udanie się do punktów obsługi i ew. kolejki w nich. Same formalności to po 10-15 minut w punkcie.

UKE proponuje, by operator do którego przenoszony jest numer, ponosił koszt (proponowane jest 25 zł). Mam świadomość, że koszt ten zostanie przeniesiony na klienta przenoszącego numer, ale samą opłatę popieram (do dyskusji jej wysokość). Sytuacja, że bardziej opłaca się kupić starter u innego operatora i przenieść do innego (zwykle są bonusy, w Play w tej chwili 60 zł na rozmowy do wszystkich sieci), generując przy tym śmieci (papier, plastik) i koszty po obu stronach, jest IMHO chora.

PS. W końcu będzie backup telefonu i okazja do porównania na żywo ofert i poziomu usług w PlusGSM i Play. 🙂

Porównanie LinkWithin i Folskr.

Zauważyłem, że ostatnio sporo ludzi z Blox interesuje się wspomagaczem linkowania LinkWithin (znanego również jako You might also like). Rozwiązanie, choć proste i popularne, niekoniecznie jest najlepsze. Postanowiłem szybko porównać LinkWithin i Folksr, którego integrację z Blox opisywałem kiedyś (patrz też wpis o Folksr na wiki Blox).

Oba rozwiązania są darmowe, działają z różnymi systemami blogowymi i mają na celu proponowanie ludziom podobnych – czyli potencjalnie również interesujących – wpisów. Parę cech różniących oba rozwiązania:

LinkWithin:

  • bierze pod uwagę temat, tagi i treść (chyba w tej kolejności, patrząc na efekty u mnie temat jest bardzo istotny)
  • potrafi sam dobrać wygląd w zależności od dostępności bądź braku zdjęć w linkowanych wpisach
  • linkuje tylko do wpisów z danego bloga
  • brak kontroli nad działaniem
  • prosta konfiguracja i implementacja
  • nieznany dokładny algorytm
  • brak statystyk (nieco widać w zwykłych, zewnętrznych)
  • tylko wersja angielska
  • bardzo popularny

Folksr:

  • bierze pod uwagę tylko na tagi (ew. kategorie; ogólnie: przekazane wprost parametry)
  • jednoznaczne, stałe dla całego serwisu określenie wyglądu linkowanych wpisów
  • linki z wszystkich blogów w Folksr, tylko wybranych („znajomych”), tylko tych, które pozwalają pokazywać także nasze linki lub tylko z naszego bloga (wybieramy samodzielnie)
  • pełna kontrola nad działaniem
  • stosunko skomplikowana konfiguracja i implementacja (patrz opis na wiki)
  • w pełni znany algorytm
  • statystyki wejść i wyjść z użyciem Folksr (osobno wejścia i wyjścia dla każdego wpisu)
  • polska i angielska wersja językowa
  • mało popularny

Ocena

Pierwsze dwa punkty to moim zdaniem remis – jednemu może bardziej odpowiadać automatyka, drugi będzie wolał większą przewidywalność. Po prostu rzecz gustu. Niestety, na Blox trochę psują efekt kiepsko zaimplementowane tagi.

Punkt trzeci to zdecydowana przewaga Folksr – w prosty sposób pozwoli na wymianę ruchu między kilkoma swoimi serwisami, albo serwisami o podobnej tematyce, jeśli tylko korzystają z Folksr.

Punkt czwarty – punkt dla Folksr. Nieduży, bo nie każdemu zależy na kontroli, ale jednak.

Punkt piąty – LinkWithin kliknąłem w minutę. Z Folksr było więcej zabawy, choć tak naprawdę nie jest to trudne, jest opisane i robi się to raz… Punkt dla LinkWithin.

Punkt szósty – kolejny punkt dla Folksr, choć znowu raczej nie dla każdego znajomość algorytmu będzie istotna.

Kolejne dwa punkty to zdecydowana przewaga Folksr. Statystyki są fajne, od razu widać, do których wpisów wchodzą ludzie, i z jakich wychodzą przy pomocy linków. Z serwisu zawsze prościej i wygodniej korzystać po polsku. Szkoda jedynie, że nie można wprost wybrać języka, wybór jest dokonywany automatycznie na podstawie ustawień w przeglądarce. UPDATE: jak trafnie zauważono w komentarzu, można samemu wybrać język.

Ostatni punkt to przewaga LinkWithin. Łatwiej o pomoc, teoretycznie większą pewność działania i przyszłość ma serwis popularny… Folksr, choć nie jest pierwszoplanowym projektem autora działa, jest funkcjonalny, ale ostatnie zmiany były dawno temu, a ilość nowych blogów, które z niego korzystają nie powala. Niemniej autor zapewnia, że serwis ma się dobrze.

Podsumowanie

Ostatecznie moim zdaniem wygrywa Folksr przewagą 5 punktów do 2 (w kolejnych 2 punktach remis).

Dla jasności: nie jestem w żaden sposób związany z Folksr. Po prostu go lubię, używam i wydaje mi się, że jest ciekawą polską alternatywą dla LinkWithin. Dodatkowo o większych możliwościach.

Yet Another Stupid Checkpoint.

Co jakiś czas łapię się na tym, że robię porządki, zmiany, podsumowania i postanowienia. Zwykle grupowo i w okolicach urlopów. Jako, że właśnie skończyłem urlop, to pora na małe podsumowanie.

Na początek rzeczy z publicznej listy TODO. Przede wszystkim, w końcu uruchomiłem produkcyjnie Dockstara. Póki co – działa i podoba mi się. Prawie pewne jest też, że pojawi się wkrótce test sprzętowego simlocka – muszę (i to szybko!) przenieść numer spam z Plusa, zapewne do Play, bo długie terminy po doładowaniach, a numer tylko na przychodzące. Zobaczymy jak to działa, zobaczymy co dalej z telefonami…

Znowu lenistwo wzięło górę i nie poszukałem kasety Bez Krótkich Spodni. Numer jeden do zrobienia przy najbliższej okazji, razem z (dopisanym w tej chwili) eksportem archiwum listy SzLUUG. Router w domu… kiedyś zrobię, najpierw kable trzeba zabezpieczyć jakoś, bo małą ciągnie i gotowa zepsuć połamać. Certyfikat IPv6 ugrzązł. Chciałem robić tylko w oparciu o publiczne, darmowe zasoby i poległem na revDNS – wygląda, że nikt z dynDNSów nie umożliwia ustawienia reva (albo za słabo poszukałem, po prostu).

Z innych sieciowych rzeczy – dziś przypadkiem sprawdziłem i okazało się, że Google podniósł blogowi pagerank (do 4). Co ciekawe, staremu, nieutrzymywanemu blogowi nie spada (nadal 3). Przypominają się ludzie ze starych projektów. Tydzień na zastanowienie i trzeba sobie jasno odpowiedzieć, czy jest sens się bawić czy kolejne rzeczy do zaorania. Tym bardziej, że są nowe plany (nie nadają się na publiczne TODO) i czas będzie potrzebny.

Z nie wpisanych na listę – zacząłem klepać kod do gry. Tak, zainspirowałem się historią RPG Idee Fixe, które powstawało latami i stwierdziłem, że skoro nic podobnego do tkwiącego w mojej głowie pomysłu nie istnieje (albo przynajmniej o istnieniu nie wiem), to będę pomału rzeźbić, bo pośpiechu nie ma. Na razie bawię się pojedynczymi funkcjami, nie wiem jeszcze, czy miałoby być to webowe, czy standalone. O ile cokolwiek powstanie, co wcale pewne nie jest… Na razie jest pomysł (miejscami mglisty), do tego napiszę parę funkcji i postaram się złożyć to w spójną całość. Potem pozostało dobranie parametrów (czytaj: prawdopodobieństw) i jakby to wyszło, to tylko pozostanie opakować w formę strawną dla przeciętnego użytkownika (czytaj: nie CLI).

Seagate Dockstar jako router.

Jakiś czas temu było o HP T5520 jako routerze, który działał i byłem z niego zadowolony, ale trzeba poznawać nowe rzeczy (w tym przypadku: sprzęt na ARM). Poza tym, z T5520 można zrobić nieco więcej, niż tylko router (ma wyjście audio, w połączeniu z MPD będzie pewnie robił za odtwarzacz radiowy, shell i NAS w innej lokalizacji). Jasne, mogłem dołożyć do Dockstara kartę dźwiękową na USB, ale ciekawiło mnie też, czy modem USB (Sagem F@st 800) zadziała na ARM.

Wybór padł na Seagate Dockstar, bo był to tani sprzęt (wówczas ~100 zł, obecnie dwa razy drożej), o niezłych parametrach (128 MB RAM, procesor 1,2 GHz). Jako alternatywa dla T5520 w tym zastosowaniu – teoretycznie idealny. I – z racji architektury ARM – znacznie bardziej energooszczędny (maksymalnie poniżej 10W poboru prądu). Last but not least – Dockstar obsługuje niemodyfikowanego Debiana.

Od zakupu do uruchomienia minęło sporo czasu. O ile instalacja Debiana była bezproblemowa, o tyle działało to nieco losowo, więc dwa podejścia spędziłem na ustalaniu, co się sypie, że czasem wstaje z Debianem, a czasem z oryginalnym systemem. W końcu doszedłem, że winny był pendrive. Faktycznie, po wymianie na inny zaczęło działać stabilnie i można było się zająć przeniesieniem konfiguracji.

Przeniesienie było proste, podłączenie modemu i… zonk. Okazało się, że debianowe kernele nie są równe, konkretnie brakowało modułu br2684. Niby żaden problem przekompilować kernel, ale jeśli mam to robić na niedużym pendrive zamiast dysku, albo crosskompilując, to tak różowo nie jest. Ostatecznie zgłosiłem błąd dotyczący braku br2684, który szybko został poprawiony.

Niestety, poprawka wyszła dla kernela w wersji 3.0 z experimental. Jakoś nie ciągnęło mnie do wrzucania na produkcyjną (choć prywatną) maszynkę takiego wynalazku, tym bardziej, że nie sam kernel trzeba wymienić. A cokolwiek innego wiązało się z kompilacją… No dobrze, niech będzie. Skoro już kompilować, to jednak 2.6 ze Squeeze. I natywnie, na Dockstarze (jakoś się na tym pendrive zmieściło po rozpakowaniu).

Pobrane źródła, pobrane i nałożone patche, korekta pliku konfiguracyjnego, make-kpkg… I zonk z kryptycznym komunikatem (niestety nie zanotowałem). Okazuje się, że make-kpkg nie potrafi sam wykryć architektury, na której jest uruchamiany. Po podaniu –arch armel (dzięki przewodnikowi po crosskompilacji dla Dockstara) poszło dalej, choć niewiele. Tym razem winne lzma i cannot allocate memory (OSLT; mimo sporego swapa – IIRC 160 MB) i tyle. A przecież nie tak dawno kompilowałem kernele na maszynach z 64 MB RAM…

Na szczęście ww. przewodnik po crosskompilacji ładnie opisuje jak stworzyć środowisko i krok po kroku wyjaśnia, jak zrobić kernel. Stwierdziłem, że skoro akcja pewnie będzie się powtarzać, to warto mieć coś szybszego do kompilacji… Opis jest bdb, używanie środowiska do crosskompilacji proste. Wystarczyło poczekać parę h (tak, kernel debianowy to krowa z masą zbędnych opcji, ale stawiałem na kompatybilność i nie chciałem się bawić…) i kernel gotowy.

Kolejna ARMowa ciekawostka to instalacja. Zwykłe dpkg -i nie wystarcza. Jak widać w przewodniku po crosskompilacji kernela, trzeba jeszcze odczynić ręczną magię z uImage i uInitrd. Z pozytywów: wstało od kopa. Jest moduł, ale… nadal nie działa. Tym razem po podłączeniu modemu masa wpisów w stylu:

ATM dev 0: usbatm_submit_urb: urb 0xc6c50b40 submission failed (-28)!

Oczywiście modem się nie łączy… Googlanie po całości wpisu nie dało efektów, ale ostatecznie, szukając po fragmentach, trafiłem na ten błąd dla OpenWRT, który sugeruje wymuszenie bulk mode. Niby wolniejsze przy większych prędkościach, ale dla łącza 1 Mbps nie stanowi. Zresztą, innych pomysłów brak, zatem:

echo "options ueagle-atm altsetting=0,0,0,0" > /etc/modprobe.d/eagle-usb.conf

W końcu działa. Nawet się połączył. Małe dopieszczenie konfigów i w końcu maszynka przeniesiona. Generalnie z odkrytych wad Dockstara: nie ma RTC, więc po restarcie startuje bez aktualnej daty i godziny. Oczywiście instalacja ntp załatwia problem po nawiązaniu łączności z Internetem, ale przy ppp chwilę to trwa i przez tę chwilę wpisy w logach będą ze złą datą.

Inna uwaga odnośnie Debiana i ARM: nie jest to tak dopracowane jak architektury i386 i amd64. Generalnie działa, ale zamiast po prostu działa, trzeba bawić się w podawanie opcji (make-kpkg) lub nawet robienie części rzeczy ręcznie (initrd).

Parę przydatnych/użytych linków, niekoniecznie występujących w treści:

Wiki Debian on Dockstar

Zgłoszenie błędu z modemem USB dla OpenWRT

Komunikaty błędu na Dockstarze dotyczące Sagem F@st 800

Opis przygotowania środowiska do crosskompilacji i zrobienia nowszego kernela dla Dockstara

Póki co, trwa niezbyt obiecująco wyglądające (wygląda, że raz się wywalił z powodu loadu…) wygrzewanie sprzętu.

UPDATE: Jednak działa stabilnie od blisko dwóch tygodni. Prawdopodobna przyczyna ww. wywałki – błędy filesystemu (pewnie z czasu instalacji, kiedy nie był read only jeszcze). Po fsck, naprawieniu błędów i reboocie bez problemu.

UPDATE2: W jednym z kolejnych wpisów opisuję jak zrobić na Linuksie router Wi-Fi. Po dołożeniu karty Wi-Fi na USB Dockstar się nada.