Czy to naprawdę kod źródłowy tego programu?

Polecam cały artykuł Is that really the source code for this software? a dla niecierpliwych lub niespikających krótkie streszczenie. Wiele wolnego oprogramowania przychodzi w postaci binarnej. Dołączony jest do niej kod źródłowy w teorii odpowiadający dokładnie temu, z którego zostały zbudowane wersje binarne. Zagadnienie jest ważne zarówno z punktu widzenia wolności oprogramowania, jak i bezpieczeństwa.

Autor ww. artykułu postanowił sprawdzić, jak to wygląda w praktyce dla popularnych dystrybucji Linuksa (Debian, Fedora, OpenSUSE). Na przykładzie tak prostego oprogramowania jak tar. Wykorzystał do tego celu minimalne instalacje systemu, korzystał ze źródeł dostarczonych w dystrybucjach i metod budowania zalecanych przez dystrybucje.

Wyniki są dość zaskakujące: ani razu nie udało mu się uzyskać dokładnej (bit w bit) kopii tego prostego przecież pakietu wykorzystując kod źródłowy.

W przypadku Debiana różnice były minimalne (data i id buildu w plikach wykonywalnych), w przypadku OpenSUSE było gorzej. Powstałe pliki binarne były 5 razy większe od oryginału. Po wykonaniu strip na wersjach binarnych sytuacja wyglądała już podobnie jak w przypadku Debiana. Najgorzej wypadła Fedora – nie tylko różnic było najwięcej, ale autorowi artykułu nie udało się ustalić przyczyn wszystkich rozbieżności . Jak pisze „niełatwo stwierdzić, czy samodzielny build ze źródeł będzie funkcjonował identycznie, jak opublikowana wersja binarna z dystrybucji”.

W przypadku skomplikowanych pakietów i projektów luźniej podchodzących do kwestii wolności oprogramowania, niż dystrybucje Linuksowe (np. firmware routerów z wykorzystaniem wolnego oprogramowania – często zamieszczają kernel, ale zwykle jest to wersja waniliowa wzięta na żywca z kernel.org…) różnice będą jeszcze większe. Gdyby ktoś znalazł komentarz RMS do sprawy, proszę o linka – bardzo jestem ciekaw, co ma do powiedzenia w tej sprawie.

UPDATE: Problem czy to naprawdę kod źródłowy danej binarki został dostrzeżony i doceniony, idea reproducible builds stała się popularna.

Jaki serwer DNS wybrać?

Wybór serwera DNS z którego korzystamy na urządzeniu końcowym jest ważny z kilku powodów:

  • Szybkość serwera DNS. Czas oczekiwania na odpowiedzi z serwerów DNS może być istotną częścią czasu ładowania stron Jest to szczególnie widoczne na stronach z dużą ilością wklejek z różnych domen. W przypadku szybkości serwera DNS nie chodzi jedynie o opóźnienie sieci (to można sprawdzić przy pomocy ping), ale o czas udzielenia odpowiedzi. Zależy on już od większej liczby czynników: opóźnienie sieci, posiadanie bądź nie odpowiedniego spisu w cache (oczywiście lepiej, jeśli odpowiada z cache), wydajność sprzętu i oprogramowania na którym działa DNS.
  • Poprawność odpowiedzi. Nic po szybkiej odpowiedzi z serwera DNS, jeśli będzie ona błędna. W skrajnym przypadku możemy paść ofiarą spoofingu DNS i trafić na podstawioną stronę.
  • Neutralność, czyli brak cenzury. Trochę wiąże się z poprzednim zagadnieniem, ale w tym przypadku chodzi o to, że do pewnych stron w ogóle nie będzie można się dostać. O ile działanie takie ma sens przy ograniczaniu zasięgu szkodliwego oprogramowania, to może być także służyć jako ograniczenie dostępu do treści.

 

Co warto zrobić w kwestii DNS?

Jeśli posiadamy sieć lokalną z kilkoma (i więcej) komputerami, to prawie na pewno warto postawić lokalny cache DNS – dzięki temu powtarzające się nazwy będą rozwiązywane lokalnie. Dobrym i prostym rozwiązaniem dla małej sieci jest dnsmasq, dostępny także dla OpenWrt.

Poza tym, warto wybrać te serwery DNS, które odpowiadają najszybciej. Zwykle nie popełnimy dużego błędu, jeśli wybierzemy serwery zalecane przez naszego dostawcę sieci lub wskazane automatycznie.

Czy zawsze lokalny serwer DNS lub oferowany przez naszego dostawcę Internetu jest najlepszy? Niestety nie. Prawie zawsze będzie on najszybszy pod względem opóźnienia sieci, ale już zawartość cache bywa różna. Szczególnie w przypadku lokalnego serwera może się okazać, że jego cache jest pusty dla większości zapytań. Na szczęście zwykle narzut lokalnego serwera nie jest duży.

Jeśli nasz komputer łączy się z internetem za pośrednictwem wielu sieci (wifi, połączenia GSM), można pomyśleć o postawieniu lokalnego cache DNS bezpośrednio na nim.

Jak najprościej znaleźć najlepsze serwery DNS?

Istnieje do tego darmowy i wolny program o nazwie namebench, służący do benchmarku serwerów DNS. Działa na wszystkich systemach, wersję dla Windows i Mac OS X można pobrać ze strony, w przypadku Linuksa zapewne jest w dystrybucyjnym repozytorium. Domyślnie działa z GUI, ale nie jest ono niezbędne – program daje się również uruchomić w konsoli. Ważne jest, żeby nie uruchamiać testu od razu, tylko najpierw przeczytać jak program działa i zastanowić się, co chcemy zrobić. Dlaczego? Ano dlatego, że pierwsze uruchomienie jest najbardziej zbliżone do rzeczywistych warunków ze względu na oryginalną, niezakłóconą poprzednimi testami zawartość cache testowanych serwerów DNS, czyli najbardziej miarodajne.

Jak korzystać z namebench?

W polu nameservers warto podać, oddzielone spacjami przynajmniej: DNS lokalny w sieci (jeśli posiadamy), serwery DNS naszego ISP. W przypadku Polski dodatkowo warto podać serwery DNS Orange (najpopularniejsze to 194.204.159.1 i 194.204.152.34) – kiedyś były dostępne tylko dla klientów TPSA, ale obecnie wyglądają na otwarte – działają z każdej sieci, z której testowałem – i osiągają dobre wyniki. W moim przypadku były szybsze, niż serwery DNS mojego ISP.

Namebench - ekran startowy
Ekran startowy namebench. Źródło: strona domowa programu namebench.

Poza tym, zaznaczamy globalne publicznie dostępne serwery cache’ujące oraz serwery regionalne. Można zaznaczyć sprawdzanie pod kątem cenzury i podzielenie się uzyskanymi wynikami. Lokalizacja to oczywiście Polska, query data source – możemy skorzystać z historii stron którejś z naszych przeglądarek, wyniki będą wówczas bardziej zbliżone do realnych.

Następnie uruchamiamy test i na kilka-kilkanaście minut zostawiamy komputer w spokoju. Po tym czasie otrzymamy wyniki: propozycję trzech najlepszych dla nas – zdaniem programu – serwerów DNS (kolejność ma znaczenie) oraz szczegółowe dane i wykresy. Kluczowy dla szybkości działania sieci jest oczywiście średni czas odpowiedzi z serwera DNS.

Na koniec uwaga: jeśli najszybsze serwery nie należą do naszego ISP ani nie są otwartymi, publicznymi serwerami, może się zdarzyć, że ich właściciel ograniczy za jakiś czas do nich dostęp.

 

Google Reader zamknięty. So what?

Niecały rok temu podniosłem fałszywy alarm o końcu grup dyskusyjnych (newsy, NNTP) w Polsce. Okazało się, że może stwierdzenie było przedwczesne, ale prorocze. Faktycznie, news.gazeta.pl został już wyłączony. Podobnie news.home.pl. Grupy dyskusyjne, które były wygodnym i popularnym środkiem komunikacji umierają. Przypuszczam, że działanie istniejących serwerów wynika raczej z tego, że wszyscy (decyzyjni) o nich zapomnieli, niż ze świadomych decyzji.

Można się zastanawiać, czemu tak się dzieje. Pewnie trochę bariera wejścia. Pewnie trochę beton wśród userów/adminów i stare reguły. Pewnie brak dostępności online (newsreadery to raczej stacjonarne twory). I w końcu pewnie brak możliwości monetyzacji. Gdyby policzyć dane przesyłane w postaci graficznej na stronach WWW, to wydaje mi się że newsy, z całym ich spamem (który z kolei stosunkowo łatwo dało się odfiltrować) miały niezły stosunek sygnał/szum, w porównaniu ze stronami i reklamami graficznymi różnej maści.

Już napisałem na FB, że nie rozumiem dramy związanej z zamknięciem Google Reader. Nie jest to ani jedyna, ani pierwsza, ani najbardziej popularna usługa zamknięta przez Google (i nie tylko Google zamyka – pamięta ktoś „zamknięcie” Delicious?). Wiadome jest, że oprogramowanie jako usługa oznacza pełną zależność od dostawcy tejże usługi. RMS, który niedawno był w Polsce i który zawsze ma przy sobie jedzenie – 34 minuta (dead link), a którego słowa tak wielu ignoruje i traktuje go przynajmniej jako dziwaka, mówi o zagrożeniach płynących z braku kontroli od dawna. W tym także o SaaS czyli Software as a Service, choćby w zaleceniach dla rządów w zakresie wolnego oprogramowania. No ale przecież po co tak utrudniać, wolne oprogramowanie takie mało błyszczące, funkcjonalności też bywają gorsze i w ogóle wygodniej jest czytać ze wszystkich urządzeń, a trzeba by coś swojego postawić, więc po co to wszystko, wezmę czytnik od Google, w dodatku za darmo. Przecież zagrożenia są przesadzone i jeszcze nie jest tak źle (cytat oczywiście z filmu Nienawiść).

Jestem pewien, że ci, którzy mówią, że Google straci, że nie wzięło pod uwagę, że grupa, której zabierają narzędzie jest specyficzna, opiniotwórcza itp. nie mają racji. Odzyskają pieniądze przeznaczone na utrzymanie bezpłatnej usługi, plus trochę więcej ludzi czytających bez RSS, które w porównaniu z tradycyjnymi stronami WWW znowu mają więcej informacji w szumie. Na stronach wyświetli się reklamy i bilans wyjdzie na zero, albo i lekko do przodu.

W sumie dobrze, że stało się, jak się stało. Może do ludzi dotrze, jak bardzo są zależni od Google. Choćby w przypadku Androida. Zresztą tu Google też się złapało za kieszeń i… usunęło z Google Play AdBlock+. No ale jeszcze nie jest tak źle, prawda? Śmieszy mnie też podział korporacji na „gorsze” (Microsoft) i „lepsze” (Apple, Google). Wszystkie mają dokładnie taki sam cel, a ewolucja metod jest jedynie kwestią czasu.

W tym przypadku dane nie zniknęły, można się przenieść. A parę miesięcy temu z podobnych przyczyn odparował kawałek dorobku – było nie było – kulturalnego/artystycznego w postaci mp3.wp.pl.