Biletomaty w Poznaniu

Wiele złego mógłbym napisać o komunikacji miejskiej w Poznaniu. Gdy się przeprowadzałem tu parę lat temu, była to jedna z lepiej zorganizowanych rzeczy w mieście. Obecnie jest jedną z gorszych, zwłaszcza dla tych, którzy nie są stałymi mieszkańcami.

Weźmy na przykład biletomaty. Zawsze były z nimi problemy, typu brak możliwości doładowania KOMkarty. Często nie działały. Ostatnio po wymianie banknotów, przestały je przyjmować. W zasadzie ostatnio jeśli chcę kupić określony bilet w określonym biletomacie, to częściej mi się to nie udaje, niż udaje. A to nieczynny, a to nie przyjmuje danej monety/banknotu…

Niedawno (przedwczoraj jakoś) na Kórnickiej nie kupiłem biletu, bo biletomat był nieczynny. Dziś patrzę, stoi nowy. Nie to, że nowy egzemplarz – w ogóle nowy model. We trzech miejscach naraz świeci, dwa ekrany, taki nowoczesny. Aż mu fotkę zrobiłem:

Biletomat Poznań

Źródło: fot. własna

Pewne rzeczy są jednak na tym świecie niezmienne. Na przykład nieczynne biletomaty w Poznaniu.

MoBILET też ma głęboko zgłoszenia awarii (i FB, i mailem na podany na stronie adres). Wychodzi na to, że nie chcą, bym kupował bilety…

Światła do jazdy dziennej

Ostatnio widuję coraz więcej samochodów, które zamiast na światłach mijania jeżdżą na diodowych światłach do jazdy dziennej. Zwykle widuję je albo w autach nowych, gdzie zapewne są montowane fabrycznie, albo w autach raczej starych, gdzie pewnie właściciele nie boją się samodzielnie przerabiać instalacji.

O ile te montowane fabrycznie zwykle spełniają swoje zadanie, o tyle te dokładane można podzielić na świecące i udające świecenie[1]. Na popularnym portalu aukcyjnym ceny kompletu zaczynają się od około 10 zł, górnej granicy nie szukałem specjalnie, ale spokojnie są też takie za ponad 200 zł. Nie wiem, czy montaż ma sens ekonomiczny (może mieć, bo takie oświetlenie to jakieś 100W mniej, plus dłuższa żywotność żarówek), ale widuję je coraz częściej.

Dzisiaj jechałem sobie na grzyby. Padał deszcz. Nie jakaś delikatna mżawka nawet, tylko normalny deszcz, taki, że wycieraczki miałem latające non-stop. I co? No i niektórzy uważają, że ich dychawiczne diodowe światła do jazdy dziennej są wystarczające. Cóż, nie są. Nawet jeśli są to wersje porządnie świecące, to w przypadku deszczu, mgły itp. po prostu nie wystarczają.

Konkurs na najgorzej oświetlone auto wygrał jakiś kierowca w nowym, małym Renault z chyba fabrycznymi okrągłymi dychawicznymi światełkami. Gdyby auto nie było białe, a szare, to podejrzewałbym go o próbę imitacji technologii stealth.

W związku z tym przyszedł mi do głowy okolicznościowy wierszyk:

Szaro, buro i ponuro?
Zapal światła! Nie bądź gułą!

[1] Nie wykluczam, że są one zgodnie z przepisami, ale efekt jest mniej więcej taki, jak w przypadku żarówek z żarnikiem w Fiacie 126p – ciężko było stwierdzić, czy to mijania, czy pozycyjne. Nawiasem, wymiana reflektorów na halogeny (H4) sprawiał, że maluchy zaczynały być widoczne i normalnie oświetlały drogę. Stare dzieje.

Bananian, czyli Linux dla Banana Pi

O Banana Pi pisałem już jakiś czas temu. Jeszcze wcześniej narzekałem na Raspbiana, że dziwne opcje ma, że bloat… Cóż, posiadacze Raspberry Pi nie mają specjalnie wyboru, natomiast w przypadku Banana Pi nie ma przeciwskazań, by korzystać z normalnej architektury armhf w Debianie. No dobrze, jest jeden wyjątek, czyli kernel…

Niedawno, po dłuższej, bo blisko dwumiesięcznej przerwie zajrzałem na forum producenta Banana Pi, a tam rzuciła mi się w oczy informacja o wydaniu dystrybucji Linuksa dla Banana Pi o nazwie Bananian. Wesoła nazwa, pomyślałem i stwierdziłem, że może faktycznie na popularności Raspberry Pi przesadnie bazują, skoro nawet Raspbiana przechrzcili… Potem wszedłem na stronkę dystrybucji, doczytałem i… jestem bardzo zaskoczony i zadowolony. Tak naprawdę autorzy poszli w tę stronę, w którą sam planowałem iść.

Czym jest Bananian? Bananian nie ma wiele wspólnego z Raspbianem, poza nazwą. To minimalna wersja (base system, zero raspbianowego bloatu!) Debiana, tuningowana pod Banana Pi (głównie kernel, plus skrypty pomocnicze). Dla pakietów (poza kernelem) korzysta z wyłącznie oficjalnych repozytoriów Debiana, czyli koniec z opóźnieniami w aktualizacjach pakietów (także security). Tuning polega na poprawieniu wydajności i bezpieczeństwa. Normalny swap (niestety włączony domyślnie), bez cudacznych skryptów. Tuning SSH pod kątem zwiększenia bezpieczeństwa zgodnie z wytycznymi z bettercrypto.org. Więcej o zmianach, ficzerach itd. na stronce.

Do tego obraz jest bardzo mały (spakowany poniżej 230 MB, po rozpakowaniu wchodzi na kartę 2GB), a developerzy sprawili na mnie znacznie lepsze wrażenie, niż ci od Raspbiana (bardziej przyjaźni i otwarci na propozycje/wiedzę).  Załapałem się na wydanie nowej wersji i nawet jakieś zgłoszone bugi na forum zostały naprawione (lub dodane do bugtrackera). Zdecydowanie Bananian mi się podoba. Taki minimalny (stronka też). 🙂

UPDATE: Projekt został zakończony, Bananian nie jest już rozwijany.

Smssender 0.9

Odezwał się użytkownik (ha! ktoś jednak tego używa! ;-)), że Mobitex przestał działać i zwraca status 104. Z racji niezbyt wczesnej pory lub po prostu zmęczenia[1], poszukałem pomocy nie u tego dostawcy, co trzeba. Ale albo statusy są zbieżne, albo dobry człowiek sprawdził we właściwej dokumentacji. Status 104, czyli brak zdefiniowanego From. Faktycznie, nie obsługiwałem tego. Tzn. była sobie zmienna w skrypcie, którą można było w skrypcie wyedytować. Niezbyt to piękne, więc w wersji 0.9 dodałem obsługę From w pliku konfiguracyjnym.

[1] Ślady zmęczenia widoczne w githubie, tak to jest jak się siada wieczorem do skryptu nietykanego od ponad roku.

Jak obliczyć wolną pamięć RAM w Linuksie?

Ile mam wolnej pamięci w systemie? to częste pytanie i użytkowników desktopów, i administratorów. Na każde pytanie istnieje prosta, błędna odpowiedź i podobnie jest w tym przypadku, choć ustalanie ilości wolnej pamięci RAM wydaje się trywialną sprawą. Większość ludzi korzysta z polecenia free, którego przykładowy wynik może wyglądać następująco (desktop):

total       used       free     shared    buffers     cached
Mem:       3926996    3614388     312608          0      82656    1305692
-/+ buffers/cache:    2226040    1700956
Swap:      1022964      20480    1002484

Typowa interpretacja byłaby zapewne w tym przypadku taka, że wolnych jest 312608 kB RAM. Niezupełnie jest to prawdą. Tzn. tyle pamięci faktycznie jest zupełnie nieużywanej, ale tak naprawdę w razie potrzeby dla aplikacji dostępne jest znacznie więcej pamięci i należałoby raczej patrzeć na drugi wiersz, nie pierwszy, czyli bliższym prawdy wynikiem jest, że wolnych w tym przypadku jest 1700956 kB RAM.

W przypadku serwerów z Linuksem, ilość wolnej pamięci łatwiej odczytać, szczególnie na potrzeby skryptów, z /proc/memifno/:

cat /proc/meminfo | head -n 5
MemTotal:        3926996 kB
MemFree:          296944 kB
MemAvailable:    1589592 kB
Buffers:           82692 kB
Cached:          1305316 kB

Patrząc na wartości z /proc/meminfo, ilość zajętej i wolnej pamięci RAM można liczyć w następujący sposób:

Free RAM = MemFree + Buffers + Cached
Used RAM = MemTotal - (MemFree + Buffers + Cached)

Jednak i to niezupełnie jest prawdą, bo do w skład Cached wchodzą np. obszary używane przez tmpfs, które nie mogą być zwolnione. Dlatego niedawno w /proc/meminfo dodano kolejną wartość MemAvailable, której zadaniem jest podawanie wprost ilości dostępnej do wykorzystania przez programy (czyli, potocznie, wolnej) pamięci. Jeśli taka wartość jest podana, to zamiast powyższych wzorów lepiej skorzystać z:

Free RAM = MemAvailable
Used Ram = MemTotal - MemAvailable

Linki:

  1. http://www.linuxatemyram.com/
  2. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

 

Piwik 2.6.0 i problemy z upgrade

Od jakiegoś czasu korzystam ze statystyk Piwik na większości moich stron ii generalnie jestem zadowolony. Do tej pory aktualizacje wersji były totalnie bezproblemowe (klikalne), ale aktualizacja wersji do 2.6.0 zakończyła się niepowodzeniem.

Od początku wyglądało dziwnie, bo kliknięcie w changelog w mojej instalacji Piwika nie pokazywało listy zmian dla wersji 2.6.0, a w dziale download najnowsza wersja opisana była jako 2.5.0 (choć faktycznie archiwum zawierało 2.6.0).

Automatyczny upgrade zakończył się klęską i pokazywaniem białej strony, postanowiłem zrobić aktualizację ręcznie, jak opisano na stronie. Okazało się, że pobrany plik piwik.zip rozpakowuje się w ślimaczym tempie (ok. 20kB/s). Także na innej, szybszej maszynie, z nowszym Debianem (unstable). Ostatecznie rozpakowałem na tej szybszej, przepakowałem do tar.gz. Przy okazji rozmiar spadł do 8MB w porównaniu z 11MB oryginalnego zip, a rozpakowanie odbyło się w normalnym tempie, czyli parę MB/s. Następnie przeprowadziłem aktualizację ręcznie.

Niewiele to pomogło, bo nadal była biała strona. Ręczne wywołanie pliku piwik.php dało więcej informacji:

PHP Warning:  require(/var/www/piwik/vendor/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php): failed to open stream: No such file or directory in /var/www/piwik/vendor/composer/autoload_real.php on line 58
PHP Fatal error:  require(): Failed opening required '/var/www/piwik/vendor/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php' (include_path='/var/www/piwik/vendor/phpunit/php-text-template:/var/www/piwik/vendor/phpunit/phpunit-mock-objects:/var/www/piwik/vendor/phpunit/php-timer:/var/www/piwik/vendor/phpunit/php-file-iterator:/var/www/piwik/vendor/phpunit/php-code-coverage:/var/www/piwik/vendor/phpunit/phpunit:/var/www/piwik/vendor/symfony/yaml:.:/usr/share/php:/usr/share/pear') in /var/www/piwik/vendor/composer/autoload_real.php on line 58

Szybki debug i znalazł się winny. W pliku /var/www/piwik/vendor/composer/autoload_files.php należy zakomentować odwołania do nieistniejących plików:

#    $vendorDir . '/facebook/xhprof/xhprof_lib/utils/xhprof_lib.php',
#    $vendorDir . '/facebook/xhprof/xhprof_lib/utils/xhprof_runs.php'

Po tej operacji wszystko działa poprawnie. HTH

http://pastebin.com/S4Hxjw6B

UPDATE: Szybcy są i czytają Twittera, już (podobno) poprawili wydając 2.6.1. 🙂

Sortowanie – Bash vs Perl benchmark

Dziś na kanale IRC znajomy szukał błędu w skrypcie bashowym. Danych dużo, skrypt wykonuje się długo (kilkadziesiąt minut). Błąd pojawiał mu się w sort, skrypt złożony. Jakoś tak stwierdził, że przepisze na Perla, będzie szybciej. Tyle tytułem wstępu, bo potem rozpoczęliśmy akademickie rozważania pt. czy sortowanie w Perlu będzie szybsze.

Postanowiłem się pobawić w praktykę. Nie ukrywam, że sporą rolę maiła tu niedawna dyskusja nt. algorytmów (i czemu zabawy z nimi są fajne) z M.[0]

Najpierw wygenerowanie sporego zestawu danych testowych [1]. 10 mln liczb z zakresu 0-99, 28999760 bajtów.

Następnie prosty sort [2]. Wyniki oscylują w granicach 16-18 sekund.

Pierwszy skrypt w Perlu[3] Jest minimalnie szybciej, bo 15 sekund.

Widać parę niepotrzebnych przepisań i da się to skrócić [4]. Po skróceniu wyniki oscylują w granicach 14,4 sekundy.

Pora na mały cheat, bo wiemy, że większość danych się powtarza. Czyli wersja z hashem – zliczamy ilości wystąpień, a na koniec sortujemy tyko klucze hasha (których jest 100) i wyświetlamy tyle razy, ile razy wystąpiły [5].

Jest dużo szybciej. Okolice 4,7 sekundy. Szczerze mówiąc nie sądziłem, że aż tyle da się urwać.

Na koniec postanowiłem sprawdzić, czy różnica wynika z powtarzających się danych. Wygenerowałem mały plik z praktycznie niepowtarzającymi się danymi [6]

Tutaj sort wykonywał się ok. 70 ms, natomiast – ku mojemu zdziwieniu – Perl nadal był szybszy i wykonywał się ok. 50 ms.

Daleki jestem od wyciągania z tego benchmarku daleko idących wniosków, nikogo też na przechodzenie wszędzie na Perla nie namawiam. Bardziej chodziło mi o pokazanie ciekawostki. Zwykle 10 sekund różnicy nie ma znaczenia, narzut na pisanie nie zwróci się nigdy, a wersja z sort jest po prostu czytelniejsza. I pewnie nadal będę używał sort. Niemniej warto wiedzieć, że w prosty sposób da się szybciej. Taki mały hack.

Inna sprawa, że IMVHO pisanie skryptów w bashu zwykle nie ma sensu i lepiej użyć Perla, Pythona itp. Szybciej, więcej można w prosty sposób zrobić, a skrypty bashowe mają tendencję do puchnięcia z elementami dziwnych rzeźb.

Uwagi: Wynik sortowania jest identyczny, choć nie to było priorytetem. Sortowanie nie jest numeryczne (jak ktoś chce, może się bawić, stawiam, że wyniki będą podobne). Skrypty są pisane mało optymalnie, mało czytelnie itd. ale tak na szybko piszę onelinery z głowy, a nie bawiłem się w upiększanie, bardziej chciałem szybko notkę zrobić. Tak, wiem nie ma close (F), w skryptach, ale nie jest tu potrzebne. Nie ma potrzeby korzystania z open, spokojnie można było robić „tradycyjne” while (<>) i czytać ze STDIN; jak sprawdziłem później nie powoduje to zauważalnej różnicy w czasie wykonania.

Ponieważ Blox wyczynia cuda z tekstami w pre podczas edycji notki, efektem czego jest znikanie większej części skryptów i tekstu, poniżej wklejka z wszystkimi poleceniami (odnośniki powyżej).

 

[0] Jest szansa, że pojawi się parę zadań z algorytmami. Ale niczego nie obiecuję. Zresztą, chyba lepiej, żeby takie rzeczy działy się na blogu jakiegoś programisty… A jak zobaczyłem, co robi Blox z groźnymi nawiasami trójkątnymi, to zupełnie odeszła mnie ochota na pisanie czegoś wymagającego fragmentów kodu tutaj.

UPDATE: Jak trafnie zauważyli czytelnicy w komentarzach, sort można przyspieszyć (analogicznie, jak przyspieszyć można grep) poprzez ustawienie LC_ALL=C lub LANG=C. Po tym zabiegu sort, dla podanych danych, działa szybciej od dotychczasowego najszybszego Perla, w okolicach 4,2 sekundy.