Na kogo głosować czyli Latarnik Wyborczy DIY

W poprzednim wpisie pokazałem, czemu nie należy zbytnio sugerować się wynikami zwracanymi przez Latarnika Wyborczego. Postanowiłem zrobić własną wersję algorytmu, która będzie wolna od opisanych wad. Z różnych względów (zajęcia poza kompem, cisza wyborcza, która jest bez sensu i pewnie nie ma zastosowania, ale dmucham na zimne) zeszło mi więcej czasu z publikacją, niż planowałem, więc wypuszczam as is. Całość zajęła nie 45 minut, tylko bardziej 1,5h (bardziej myślenie, niż klepanie), po poprawkach błędów różnych.

Założenia

  • KISS
  • Brak odpowiedzi na pytanie jest traktowany tak samo jak neutralność w danej kwestii lub nie mam zdania.
  • Wynik jest wartością -100% do 100% (lub, w wersji drugie, bardziej zgodnej z LW 0-100%).
  • Waga pytania nie powoduje drastycznej zmiany wyniku

Rozwiązanie

Stwierdziłem, że tak naprawdę da się to sprowadzić do liczenia korelacji. Czyli nie programowanie, tylko arkusz kalkulacyjny. Zresztą łatwiej debugować błędy. Kwestię prostoty i neutralności łatwo osiągnąć przez przypisanie wartości -1 (nie), 0 (brak zdania), 1 (tak). Zarówno dla odpowiedzi kandydatów, jak i odpowiadających. Ciocia matematyka zapewni, że zwykły iloczyn użytkownika i kandydata da 1 dla zgodności, -1 dla wartości przeciwnych i 0, jeśli którakolwiek ze stron nie ma zdania.

Powstał wiec arkusz z czterema zakładkami

Odpowiedzi kandydatów

Przepisane żywcem z wyników zebranych i publikowanych przez Latarnika Wyborczego (prośba o sprawdzenie, przepisywanie do arkusza to nudna część i łatwo o pomyłkę, więc nie wykluczam błędów, choć starałem się wypełnić rzetelnie). Część stała, nie wymaga żadnej ingerencji.

Odpowiedzi i istotność

To jest część, którą tak naprawdę wypełnia użytkownik odpowiadając na pytania w Latarniku Wyborczym. Brzydka forma, bo nie o UI mi chodziło. Dla każdego pytania podawana jest odpowiedź [-1, 0, 1] oraz istotność (po prostu mnożnik, zakres tak naprawdę dowolny[1], intencją był zakres 0-2, przyjąłem zmianę o 20%, nie musi być równa dla wszystkich pytań). Pola wypełnione na żółto wypełnia użytkownik (w arkuszu wypełnione są przykładowymi, losowymi danymi).

Obliczenia wyników

Tu zaszyty jest algorytm. Prosty, bo po prostu jest to iloczyn uzyskanego wyniku (suma ilorazów wagi, odpowiedzi kandydata i użytkownika) i maksymalnej teoretycznej zgodności[1]. Część stała, nie wymaga ingerencji.

Wynik

Tu jest to, co użytkownik dostaje na koniec. Podaję w dwóch równoważnych wersjach, różnią się tak naprawdę tylko zakresem. Pierwszy to -100% (zdanie przeciwne do kandydata dla każdego pytania) do 100% (wszystkie odpowiedzi jak kandydat), 0% oznacza wynik neutralny. Drugi wariant to po prostu rzutowanie na 0-100%. 50% oznacza brak jakiejkolwiek zbieżności poglądów z kandydatem, 0% – poglądy dokładnie przeciwne, 100% – poglądy zupełnie zgodne. Mniej więcej odpowiednik tego, co jest teraz w Latarniku Wyborczym (dla neutralnej wagi pytań). Część stała, nie wymaga ingerencji.

Sposób użytkowania

Pobrać arkusz ze strony (format ods, działa w darmowym Libre Office), uruchomić. Przejść do arkusza Odpowiedzi i istotność, wypełnić żółte pola. Po wypełnieniu wynik odczytujemy w zakładce Wynik. Oczywiście całość jest open source, czyli każdy może wprowadzić swoje poprawki i modyfikacje. Oraz poszukać błędów, których nie wykluczam.

Uwagi proszę zgłaszać w komentarzach pod wpisem. Spam, także wyborczy AKA agitacja będzie tępiony.

[1] I tu, kończąc wpis, widzę pierwszy błąd mojego rozwiązania. Powinienem jeszcze przemnożyć odpowiedzi kandydatów przez mnożnik podany przez użytkownika, gdy liczę maksymalny wynik dla kandydata. Teraz możliwe jest uzyskanie wyniku ponad 100%, zwł. dla wyższych mnożników. Błąd znany, poprawka trywialna, ale nie chce mi się teraz tego robić, jak będzie zainteresowanie to poprawię.

Upał

Przejście z jesieni w lato było dość gwałtowne w tym roku. Co prawda wiosna, i to ciepła przyszła już dawno, ale niedawno zrobiło się zimno, pochmurno i w ogóle nieciekawie. Ale od paru dni w Poznaniu zrobiło się lato pełną gębą, z temperaturami rzędu 30 C. Sporo i mocno odczuwalne, z uwagi na gwałtowność zmiany.

Zmiany temperatury o dziwo dotknęły też mojego NAS opartego o Raspberry Pi. Piszę o dziwo, bo w sumie stoi blisko grzejnika i myślałem, że głównie zimą będzie tam gorąco. O ile 40 C na dysku (samo rpi mnie mało interesuje, dopóki się nie wiesza itp.) zostało przekroczone już dawno, to do tej pory utrzymywało się 41-42 C. No chyba, że pojemnik został czymś przykryty, co się zdarzyło raz czy dwa, ale można uznać za nieistotne odstępstwo od normy. Natomiast odkąd zaczęły się upały, dysk zgłaszał cały czas temperatury 44-45 C. Nawet i 46 się zdarzyło, a tak przecież nie mogło zostać. Tym bardziej, że bliźniak leżący luzem (OK, inna lokalizacja) ma w tej chwili 35 C, a 46 to jego życiowy rekord.

Postanowiłem machnąć ręką na uptime (nie, nie zbieram i generalnie nie zwracam uwagi, ale nie lubię wyłączać sprzętu) i dorobić otwory. Z poprzednich sześciu otworów wylotowych u góry obudowy (po 3 sztuki na dwóch ściankach) zrobiło się… 20 (po 5 na każdej ściance). Dodatkowo dorobiłem po 3 sztuki otworów wlotowych w dolnej części ścianek. Mam wrażenie, że filcowe nóżki są jednak trochę za niskie. Zobaczę, czy to coś pomoże… Jeśli nie, to będzie trzeba pomyśleć o jakimś separatorze pomiędzy rpi a kieszenią z dyskiem i może o podwyższeniu nóżek. W sumie w odwrotnej kolejności, bo wpływ podwyższenia nóżek łatwo przetestować prowizorycznie podkładając choćby dwa ołówki. 😉

Przy okazji, skoro już było wyłączenie z prądu, skorzystałem z watomierza i sprawdziłem, ile prądu bierze Raspberry Pi. No, w zasadzie cały zestaw, bo samego rpi nie mierzyłem. Więc hub USB + rpi + dysk 2,5″ biorą u mnie przy normalnym działaniu 5,2W. Przy obciążeniu CPU (prosty Perl) wzrasta to do 5,9W. Najbardziej obciążające jest kopiowanie na dysku USB z partycją NTFS – typowo 7,3W, maksymalnie 8W.

Raspberry Pi jako NAS

Nie bardzo miałem co zrobić z moim Raspberry Pi, a przecież nie może się maszynka nudzić. Przy czym łącze do domu mam całkiem fajne i w praktyce po WiFi nie do wykorzystania[1], więc postanowiłem zrobić sobie seeder torrentów[2], serwer do backupu innych maszynek i ogólnie NAS dla domu. Niby coś jak Dockstar, ale nie głównie router, tylko z akcentem na NAS. W sumie może kiedyś dorzucę mini hosting dla własnych gadżetów. Na razie leży to sobie na dedyku, zresztą rpi demonem szybkości nie jest, więc z czymkolwiek ponad statyczne strony może być ciężko…

Nierozwiązaną miałem kwestię obudowy dla Raspberry Pi. Przy czym, gdybym zrobił to tradycyjnie, to byłby hub USB, kabelki do rpi, kabelki do dysku, kabel do zasilania, kabel do routera. Trochę plątanina, którą ciężko utrzymać w czystości, bo ani odkurzyć porządnie, ani przetrzeć szmatką. No i podatne na usterki, bo taki kabel na wierzchu jednak łatwo szturchnąć. Postanowiłem, że spróbuję upchać to wszystko w jedno pudło i zacząłem rozglądać się za jakimś dającym się wykorzystać gotowcem.

Pierwsze co mi wpadło w oko, to pudełka do żywności w Netto. Trzy sztuki (różnej wielkości) za 8 zł. Szybka przymiarka ujawniła, że średnie, na które liczyłem się nie nadaje, bo jest za małe. Za to największe pasuje. Na styk, zresztą, ale to dobrze – można zrezygnować z mocowania elementów w środku. Trochę bałem się, że plastik nie będzie odporny na temperaturę, ale niesłusznie. Według opisu pojemniki są przeznaczone do temperatur od -30 do +100 C i do użytku w mikrofali.

Układ elementów w pudełku następujący: na dole dysk w kieszeni, jako element najchłodniejszy i najcięższy, ma lekko miękkie etui z tworzywa, więc na nim bez obaw mogę położyć Raspberry Pi. Hub USB Unitek przymocowany do pokrywki przy pomocy opasek samozaciskowych (AKA żmijki). Po pierwsze jest metalowy, więc nie chcę go mieć w pobliżu rpi z uwagi na możliwe zwarcia, po drugie jego ażurowa obudowa sugeruje, że może się grzać. Pierwotnie rpi miało leżeć wzdłuż dysku, ale nie pasowało to do układu kabli. Zresztą jest na tyle małe, że w poprzek też praktycznie nie wystaje poza obrys dysku.

Miałem obawy o temperaturę w środku, bo wymiana powietrza jest mocno utrudniona. Nie było źle – S.M.A.R.T. dla dysku pokazywał góra 40 stopni, ale ostatecznie zdecydowałem się na dodanie otworów od spodu pudełka (w zamyśle wlot zimnego), zrobienie nóżek z podkładek filcowych (samoprzylepne do mebli) w celu umożliwienia dopływu powietrza do nich, oraz kilku otworów na samej górze z boku (w zamyśle wylot ciepłego powietrza; nie pokrywka, żeby kurz nie wpadał od góry do środka). Dzięki temu jakiś tam przepływ jest i odrobinę chłodniej.

Uroki notek po czasie są takie, że mogę napisać, jak to działało i czemu przestało. Działało bardzo dobrze i stabilnie. Jedyne restarty to braki prądu (rzadko się zdarza, ale się zdarza) lub wymiana kernela. Uptime po kilkadziesiąt dni. Wydajnościowo szału nie ma. Sam NTFS via ntfs-3g potrafił wskoczyć w top na pierwsze miejsce z kilkadziesiąt procent (40-60) zużycia CPU. Oczywiście NTFS jest tam tymczasowy – po prostu chwyciłem do testu dysk, który robił za przenośny. No i całość jak najbardziej wyrabiała się z serwowaniem plików po sambie po WiF. Tyle, że cokolwiek więcej w tym czasie na rpi było problematyczne. Dysk po USB jak najbardziej daje radę, ale ten element miałem przetestowany już wcześniej.

Dzięki temu, że miałem notkę o testowym uruchomieniu Raspberry Pi, wiem dość dokładnie, ile działało. Problemy (niemożność zalogowania się po SSH) zaczęły się na początku kwietnia, czyli podziałało jakieś 4 m-ce. Niestety, trafnie przewidziałem powód: pad karty micro SD (ja wiedziałem, że tak będzie… pamięci flash nie nadają się do zapisu ja wiedziałem, że tak będzie…). Początkowo uważałem, że to zwykłe zawieszenie, ale po restarcie po paru godzinach sytuacja się powtórzyła. Wyjąłem kartę, w komputerze popełniłem backup przez obraz partycji, następnie fsck (były błędy) i przy okazji zdjąłem journal z ext4. Podziałało jeszcze parę dni i sytuacja znowu się powtórzyła. Tym razem sprawdziłem dokładniej. Badblocks widzi błędy na karcie, zarówno na teście odczytu (jeden), jak i niedestrukcyjnym teście zapisu (więcej). Próbowałem reanimować przez oznaczenie przez fsck sektorów jako uszkodzonych (patrz przydatne polecenia Linux), ale bez powodzenia. Po naprawie rpi już się nie bootuje z tej karty.

Nie jestem w stanie stwierdzić, czy winien był – niestety domyślnie w Raspbianie włączony – journal, czy zapisywanie przez transmission stanu co kilkanaście minut na dysk (kartę) gdzieś w /var. Symlinka i przenoszenia na dysk twardy nie robiłem. Po pierwsze i tak system był z journalem, po drugie, chciałem zobaczyć, na ile to szkodliwe dla karty. Jak widać jest szkodliwe i karta potrafi paść w mniej niż pół roku. Co prawda widzę karty Goodram 4 GB za ok. 10 zł, ale nie widzę sensu w grzebaniu i ew. utracie danych.

Niebawem, po kupnie karty (tak się pechowo składa, że nic wolnego większego niż 2 GB chwilowo pod ręką nie mam), wskrzeszę system. Być może kupię docelowy dysk do kieszeni i wtedy zrobię od razu root montowany w trybie read only. Nawet jeśli nie, to od razu po instalacji zdejmę journal z ext4, prawdopodobnie zajmę się też od razu transmission…

Kiedyś pojawią się tu zdjęcia – leżą na dysku, który był podłączony do NAS, a nie chce mi się podłączać go bezpośrednio do kompa…

[1] Bo router to WRT54GL, który co prawda linkuje się na 54 Mbit bezprzewodowo, ale realnie komputery wyciągają ok. 20 Mbps. Po wpięciu na kablu nie ma problemu. W eterze umiarkowany syf, wybrany najlepszy kanał i tryb G only. Ogólnie 802.11n by się przydało, ale przecież router działa, a szczerze mówiąc nie sądzę, bym zobaczył różnicę – 20 Mbps to kosmos. Chociaż znajomi donoszą, że przy 802.11n poprawia się zasięg, więc pewnie się skuszę…

[2] Żadne tam nielegale, po prostu mały wkład w projekty open source. Seedują się netiso Debiana (trzy architektury), pierwszy CD Debiana (trzy architektury), t(a)ils, tego typu sprawy. Zresztą pisałem o tym już (uroki niechronologicznego publikowania notek).

UPDATE: W jednej z kolejnych notek opisuję, jak zrobić z maszynki z Linuksem router GSM/Wi-Fi. Z uwagi na niewielkie rozmiary i mały pobór energii Raspberry Pi nadaje się do tego bardzo dobrze.