Wii Motion ovladač jako joystick v Linuxu

Dnes jsem zkoušel použít Wii Motion ovladač od zaprášeného Nintendo Wii jako joystick v Linuxu. Postup není triviální a zatím ani nevede k úplnému úspěchu, takže následující řádky jsou jen mým povzdechnutím dokumentujícím, kudy jsem šel a kam jsem se to (zatím) dostal:

1) Wii Motion ovladač komunikuje s Wii přes bluetooth, takže jde spárovat i s PC (pokud má BT, což třeba většina notebooků má). Chvilku mi trvalo to naklikat, ale nakonec se to povedlo. Od té chvíle začne zlobit kurzor myši, protože Xorg použije nově vytvořené HID zařízení a tak Wii Motion začne nějak divně ovládat i myš (stejně jako tlačítka na ovladači fungují jako klávesy či tlačítka myši).

2) po instalaci debian balíčku xwiimote a následném odhlášení a přihlášení zpět se uklidní pracovní prostředí, protože do /usr/share/X11/xorg.conf.d/ přibyde 50-xorg-fix-xwiimote.conf, který říká, aby byl Nintendo ovladač jako vstupní zařízení ignorován. V tu chvíli už také existuje /dev/input/js0 - tedy zařízení reprezentující v systému joystick, ale má pouze 7 tlačítek, žádné páky. Ani nefungují tlačítka na směrovém kříži, takže je toto joystickové zařízení k ničemu.

3) pak si z githubu může člověk stáhnout projekt wiimote-pad, který po kompilaci a spuštění pod rootem vytvoří nové joystickové zařízení /dev/input/js1, které už má 11 tlačítek a dva analogové směry. Jako směry se používá akcelerometr (takže nakláněním ovladače), a 4 nová tlačítka už zahrnují směrový kříž. Stačí si nainstalovat aplikaci jstest (jstest-gtk) a vyzkoušet si to.

V tuto chvíli už se dá Wii Motion ovladač použít jako analogový joystick se spoustou tlačítek. To mi ale nestačilo, chyběly mi hned tři věci:

1) chtěl bych směrový kříž mít jako pákový ovladač, abych mohl hrát hry, které čekají pákový ovladač, normálně těmi tlačítky, bez přemapovávání na klávesy.

2) chtěl bych mít podporovaný i nunchuck - ten tam teď vůbec není vidět, ačkoliv je připojen.

3) toto nové zařízení není rozpoznáno SDL knihovnou. Prostě ten joystick nevidí, takže je všechno stejně v háji. Netuším, čím je to virtuální zařízení js1 divné, že ho SDL nevidí.

Když se člověk pořádně rozhlédne po Githubu, zjistí, že wiimote-pad má hned tři forky, z nichž jeden implementuje směrový kříž jako ovladač, a druhý fork pak podporuje Wii nunchuck. Takže první dva body z mého seznamu by se daly vyřešit!

To by bylo super, kdyby to ovšem šlo zkompilovat. Chybí ale deklarace některých konstant. Při bližším zkoumání člověk zjistí, že Debianní /usr/include/xwiimote.h není úplně aktuální, přestože se projekt nevyvíjí už od roku 2013. Do Debianu se dostala verze 2.3 (z léta 2013), ovšem těsně poté (v srpnu) původní autor ještě komitnul na Githubu pár drobných, ale klíčových změn.

Takže by to chtělo nejdřív aktualizovat knihovnu/balíček libxwiimote-dev. Ovšem odkud? Projekt xwiimote má na Githubu 22 forků, z nichž některé obsahují mnoho užitečných změn přidávaných po další 4 roky. Nikdo z těchto autorů se už ale nesnažil to nějak spojit s ostatními...

Tudíž by to chtělo zjistit, kdo co přidal do xwiimote ve svých forcích, poslepovat z toho nějakou nejlepší verzi, tu dostat do Debianu nebo nějak polo-oficiálně vydat, na základě toho pak nějak dát dohromady wiimote-pad slepením vylepšení z těch tří forků, to ještě nejspíš upravit tak, aby mi to vyhovovalo, a pak i toto slepeniště nějak vydat pro další lidi, kterým by se to mohlo hodit.

Jo a samozřejmě je nutné nějak opravit to virtuální zařízení js1, aby fungovalo v SDL. A pak nějak vymyslet, jak zamaskovat zařízení js0, které v tu chvíli už není potřeba a jen tam zavazí (bude se vnucovat do všech programů jako první joystick ze dvou).

Docela dost práce, na kterou teď nemám čas, tak jsem si aspoň zapsal postup cesty sem a třeba se někdy vydám dál tím správným směrem...

P.S. teď mě napadá, že správně by se měl opravit ovladač přímo v Xorg, aby už to prvotní zařízení js0 fungovalo rovnou správně a nemuselo se nic dalšími programy napravovat. Hmmm, no to je ještě větší oříšek - to než bych zvládl, tak by Xorg zmizel v propadlišti dějin (kam má už teď díky Waylandu slušně nakročeno - ve Fedoře už ani není, a v novém Ubuntu 18.04 měl štěstí jen o vlásek).

Přednáška o Orange Pi na LinuxDays 2017

Installfest a LinuxDays

Přednášku věnovanou jen Orange Pi jsem měl na jaře na Installfestu. Tudíž na LinuxDays jsem se chtěl zaměřit především na novinky, abych se moc neopakoval. Bohužel na přednášku jsem měl v programu jen 25 minut, takže jsem už předem věděl, že toho moc říct nestihnu. Téma Orange Pi a vůbec těch malých jednodeskových počítačů v čele s Raspberry Pi je nesmírně obsáhlé a dalo by se o něm hovořit a hlavně předvádět různé věci celé hodiny.

Prezentaci z přednášky v PDF najdete tady: https://www.pstehlik.cz/prezent/

Zbytek tohoto článku shrnuje, doplňuje a opravuje informace, které zazní ve videu z letošních LinuxDays:

Raspberry Pi

Kromě Raspberry Pi s jeho novým desktopem Pixel (dostupným i pro Mac a PC) je zajímavé, že máme oficiálního českého distributora, díky čemuž už ceny Raspberry Pi Zero nedosahují takových výšin. Původně Zero nebylo dlouhodobě dostupné, případně se prodávalo v balíčku s tolika nesmyslnými kabely a redukcemi, že to vyšlo dráž, než si ho poslat přímo z UK. Nyní je to za 157 korun myslím velmi dostupný gigahertzový stroj.

ODROID a další

Dále jsem chtěl využít toho, že mám osobní zkušenosti s platformou ODROID a jejich nejvýkonnějším modelem XU4. Přivezl jsem jeden kousek a nechal ho kolovat, aby si návštěvníci LinuxDays mohli osobně zblízka osahat jihokorejskou kvalitu. XU4 má už několik let USB3 port, gigabitový ethernet a hodiny zálohovaného času, takže je velmi vhodný na všechna ta serverová nasazení s externími disky, kde lidé pořád nesmyslně trápí Raspberry Pi. Osobně jsem na ODROID XU4 vyvinul rozpoznávání obrazu v reálném čase, kdy všech 8 jader jede naplno a paralelně rozpoznávají následující snímky z kamery. Na Raspberry Pi by něco podobného bylo 4x pomalejší, tedy mimo reálný čas.

ODROID XU4

Stručně jsem prolétl i ostatní konkurenty na poli SBC, ale nezacházel jsem do detailů, neboť je neznám. Publikovat údaje z marketingových letáků jsem nechtěl, protože se často hodně rozcházejí s realitou v praxi.

Vlastní Orange Pi

Konečně jsem se dostal k Orange Pi, kde jsem stručně prošel všechny čtyři kusy, se kterými mám osobní zkušenost: Orange Pi Plus, Orange Pi One, Orange Pi Zero a Orange Pi PC Plus - ten poslední jsem si koupil speciálně kvůli letošním LinuxDays, neboť jsem doufal v živou ukázku. Měl jsem nainstalovaný systém z www.h3droid.com, který je velmi zajímavý tím, že na začátku nainstaluje něco jako "grub" - jednoduchý, ale mocný systém pro instalaci a konfiguraci dalších věcí, a to nejen Androidu, ale i Armbianu.

Orange Pi Zero

Ve výsledku mám nyní na SD kartě dual boot, tedy při startu možnost vybrat jeden ze dvou různých operačních systémů - Android nebo Debian. Je to velmi pohodlné a mocné - člověk tak rychle porovná například stav hardwarové akcelerace grafického výstupu nebo HDMI CEC, které prý u tohoto konkrétního typu opravdu funguje.

Orange Pi PC Plus

Tři důležité novinky u Orange Pi

Dále jsem chtěl zdůraznit tři velmi důležité novinky z Orange Pi "kuchyně". Za prvé - firma Shenzen Xunlong Software je nesmírně rychlá, neustále rostoucí a má skutečně velké ambice. Brzy bude produkovat takové množství hardware, že snad doroste i Raspberry Pi. To pro uživatele znamená, že se zřejmě nemusejí obávat, že by Orange Pi jakoby "zmizelo z trhu".

Druhá důležitá novinka je, že se firma vyrábějící hardware snaží o lepší softwarovou podporu - ať už partnerstvím s Ubuntu, anebo finanční podporou Armbianu, který je defacto jediným fungujícím operačním systémem pro Orange Pi.

Třetí novinkou, především pro české uživatele, je nově vzniklá skupina na Facebooku, kde se česky/slovensky domlouvají mezi sebou uživatelé (nejen) Raspberry Pi. Běžně se lidé trochu bojí koupit si něco jiného než Raspberry Pi, protože cítí, že by mohli s exotickým čínským hardwarem zůstat osamoceni jako kůl v plotě. U Orange Pi už to myslím nehrozí - kromě obří mezinárodní anglicky hovořící skupiny na Facebooku (8000+ členů) je tu nyní nejméně 200 československých lidí připravených sdílet své zkušenosti. A to je pro rozšiřování Orange Pi zásadní věc.

H5? H5!

Velmi zajímavé je, že jsem chtěl přednášku využít též jako varování uživatelům, kteří by si chtěli koupit některé z novějších Orange Pi s 64bitovým Allwinner H5 procesorem. Podle informací z Armbian fóra i facebookové skupiny jsem věděl, že procesory H5 nemají dobrou SW podporu - nová linuxová jádra na nich neběžela vůbec, takže uživatel byl odsouzen k používání starého děravého jádra od výrobce. Před tímto jsem na přednášce v sobotu 7. října varoval a měl jsem dobrý pocit, že jsem možná někoho uchránil před zklamáním.

Ovšem už o pouhé tři dny později, v úterý 10. října, se všechno změnilo! Igor slavnostně oznámil, že po mnoha měsících tvrdé práce pár dobrovolníků nyní Allwinner H5 běží i s nejnovějším jádrem Linuxu! A aby toho nebylo málo, už následující den oznámil tuším NetBSD taky plnou podporu pro Orange Pi s Allwinner H5! Takže celé měsíce nic, a naráz si člověk může vybrat hned ze dvou kvalitních operačních systémů. To je skvělé!

Závěrem

Jednou bych si chtěl najít 3 hodiny času a udělat přehlednou srovnávací tabulku všech typů Orange Pi, které Xunlong aktuálně chrlí - ovšem už za další měsíc by ta tabulka byla neaktuální, protože tak rychle na trh uvádějí nové modely. Je jich skutečná záplava a je kumšt si vybrat správně. Snad jsem svou přednáškou aspoň trošku pomohl ukázat jak levné modely (Zero, One), tak i "střední" třídu (Plus, PC Plus). Nejvýkonnější 64bitové novinky či specialitky typu GSM IoT nebo dvousíťové routery jsem ještě v ruce neměl, tak jsem o nich zatím mluvit konkrétně nechtěl. Ale jak se znám, u čtyřech pomerančů neskončím a časem nakoupím další, tak třeba za rok budu mít nové zkušenosti či zprávy, o které se budu chtít někde podělit :-)

OctoPrint - instalace na Orange Pi

Jak se vlastně 3D tiskne

Už přes půl roku mám 3D tiskárnu i3 MK2 a tisknu na ní různé roztodivné věci:

Vybraný model k tisku je obvykle ve formátu STL. Ten musím nařezat na plátky (naslicovat) a pak z nich vygenerovat instrukce pro pohyb tiskové hlavy, tiskové podložky a dávkování roztaveného plastu - tzv. G kód (čistě textový soubor s koncovkou .gcode).

Tento soubor s pokyny potom načítá mikrokontrolér v tiskárně a jednotlivé pokyny postupně vykonává. Tiskárna má k tomu vestavěný vlastní maličký mikropočítač se čtečkou SD karet, displejem a jedním otočným ovládacím knoflíkem. Stačí soubor s G kódem nahrát na PC na (mikro)SD kartu, tuto přenést k tiskárně, vložit do její čtečky karet a nechat vytisknout.

Toto funguje spolehlivě, ale brzy začne být přenášení paměťové karty mezi PC a tiskárnou méně a méně zábavné, později dokonce více a více otravné. Displej na tiskárně má malé rozlišení, není jednoduché vybrat mezi vícero soubory připravenými k tisku. Informace během tisku jsou minimální - jen procenta načtení souboru a aktuální výška výtisku. Chtělo by to nějak vylepšit.

Tiskárnový mikrokontrolér jde ovládat i přes USB. Můžeme například připojit tiskárnu přímo k pracovnímu PC a díky programu Pronterface posílat instrukce G kódu přímo z PC po USB kabelu. Během tisku vidíme mnohem víc informací, třeba grafy s teplotami podložky a tiskové hlavy, nebo aktuální pozici hlavy na tiskové vrstvě atd. Vypadá to, že takto je to pohodlnější než neustálé přenášení karty sem a tam.

Ovšem pak zjistíme, že u 12hodinového tisku nemůžeme vypnout PC, protože by se tisk přerušil. Nemůžeme ho ani restartovat (třeba kvůli aktualizacím). A když se rozhodne nejmenovaný systém jedné monopolní firmy restartovat sám (jak to má v oblibě), zničí tím celý mnohahodinový tisk. Program taky nesmí spadnout, USB nesmí nikdo rozpojit, s notebookem nesmíme nikam odejít atd. Ani toto není ideální.

Nejlepší řešení by bylo věnovat jeden počítač jen a pouze tiskárně. Mohl by být přístupný po síti nebo i z Internetu, umožnit tisky pouštět, hlídat a v případě poruchy zastavovat i na dálku, mohl by mít připojenou kamerku, takže bychom mohli tisknout a přitom si třeba odskočit na pár hodin "na jedno" a přitom mít dokonalý vizuální přehled, jako bychom se od tiskárny nevzdálili ani na krok. Nic jiného by na tomto počítači neběželo, žádné aktualizace a další zdroje poruch - prostě specializovaný, dedikovaný počítač jen pro tiskárnu. A mohl by mít pěkné webové rozhraní, které by všechno umožnilo řídit. To by asi bylo ideální.

OctoPrint

No a protože žijeme v úžasném světě svobodného software, tak tento řídicí program s pěkným webovým rozhraním a mnoha dalšími vymoženostmi už existuje - jmenuje se OctoPrint - a je dostupný zdarma a se všemi zdrojovými kódy (vývoj probíhá na GitHubu). Kdybych chtěl být genderově nekorektní, nebo dokonce pozitivně diskriminační, zmínil bych i tu zajímavost, že tento skvělý program vyvíjí žena - Gina Häußge. Ale protože na pohlaví u programátorů nehledíme, tak jen zmíním, že je dobré jí přispět nejen kvalitním bug reportem, pull requestem s nějakým vylepšením, ale i třeba drobnou mincí (Patreon, Paypal), protože OctoPrintu věnuje spoustu času a musí taky z něčeho žít.

Takže software máme (v Pythonu, tedy přenositelný na jakoukoliv platformu) a chybí už jen počítač. Místo PC, které je neskladné, žere elektřinu a točí se v něm součástky, bude mnohem lepší volbou jednodeskový minipočítač. Například něco jako Raspberry Pi za 35 dolarů (plus dražší poštovné plus smrt na poštovní celnici za překročení limitu). Pro Raspberry Pi existuje hotový obraz paměťové karty s předinstalovaným operačním systémem a OctoPrintem - jmenuje se OctoPi a není s ním žádná práce, takže tady by mohl tento návod končit.

Orange Pi

Pokud jste ale fandové levnějšího ovoce než Malin z Anglie, můžete číst dál. Popíšu totiž, jak jsem OctoPrint nainstaloval na Pomeranč z Číny, tedy Orange Pi od Shenzhen Xunlong Software. To ale není moc důležité, protože rozumný operační systém pro tyto malé počítače - Armbian - běží na desítkách různých desek, takže tento postup jde aplikovat i na Banány, Borovice a mnohé další stroje.

Konkrétně jsem použil Orange Pi One za necelých 10 dolarů (plus levné poštovné $3.61). K němu jsem rovnou přikoupil i originální 2Mpix kamerku. Není to žádný zázrak, ale za necelých 6 dolarů paráda. Tím pádem jsem byl hluboko od obávaným celním limitem a za pouhých 400 českých korun získal počítač, který bude jen a pouze sloužit tiskárně.

Pokud bych nechtěl použít originální kamerku k Orange Pi, ale sáhl místo toho po nějaké s USB rozhraním, mohl bych vzít ještě levnější počítač - Orange Pi Zero za neuvěřitelných 6 dolarů. Zero totiž nemá CSI konektor pro kameru, bohužel. Anebo kterýkoliv jiný Orange Pi, jejich výrobce se zbláznil a skoro každý měsíc vychrlí nový typ...

Instalace HW

Instalace "železa" vyžaduje vyrobit či sehnat kryt na počítač, protože nechceme nic zkratovat. Nejlepší je kryt si sám vytisknout. Na Thingiverse jsem našel krásný hotový model.

Dále potřebujeme držák na kameru. Opět nejlépe vytisknout, a zase jde najít hotový model držáčku kamery na Thingiverse.

Teď je potřeba počítač přichytit třeba na rám tiskárny, kde nebude zavazet, zatímco kameru je potřeba postavit tak, aby viděla na tiskovou plochu. Bohužel, originální kamerka připojená přes CSI rozhraní může mít jen kratičký kablík, takže je nutno najít takovou pozici pro počítač, kde bude mít kamerka dobrý výhled. Toto jsem v době psaní tohoto článku ještě nevyřešil...

USB kamerka by zde byla výhodnější, neboť USB kablík může být mnohem delší, takže počítač by mohl být zezadu na rámu tiskárny, a kamerka jen na nějakém měkkém drátku nastavena někde z boku tak, aby pěkně viděla na scénu.

Počítač můžeme napájet originálním zdrojem z další zásuvky, ale do budoucna se chystám spíš udělat rozdvojku na USB vedoucím z mikrokontroléru tiskárny a napájet Orange Pi přímo z tiskárny. Jestli si na to koupím kablík pro napájení z USB, nebo jestli se připojím přímo na piny konektoru v Orange Pi, ještě netuším, ale obě možnosti jsou schůdné.

V neposlední řadě je dobré nezapomenout na osvětlení tiskové plochy. Určitě postačí pár jasně bílých LEDek, nejlépe taky napájených z USB tiskárny, ať je všechno na jednom zdroji. Fajnšmekr by dokonce mohl k počítači připojit senzor úrovně okolního světla a řídit svit LEDek podle toho (přes den vůbec, v noci na max, ale jen při tisku, samozřejmě).

Zajímavé by mohlo být osvětlit pracovní plochu infračervenými LEDkami a snímat kamerkou bez IR filtru. Pak by tisková sestava nepřispívala ke světelnému smogu (zbývá ještě hlukový smog a plastový smrad, což vyřeší jedině separátní tiskařská kobka s odsáváním zplodin).

Instalace SW

Tak za prvé nainstalujeme určitě operační systém, tedy rozhodně Armbian. Stáhnout správnou verzi na PC, zapsat na paměťovou kartu, vložit do Pomeranče a nastartovat. Napoprvé se tam dějí věci (rozšiřují diskové oddíly), tak je potřeba to nechat, případně restartovat, updatovat balíčky atd. Přesný návod najdete u Armbianu.

Dále můžeme instalovat samotný OctoPrint. Postupujeme podle návodu pro Raspberry Pi, protože Debian jako Debian (tj. Raspbian jako Armbian). Jeden důležitý balíček jim tam (kvůli chybě v Debian Wheezy) ale chybí - "virtualenv". Takže do příkazové řádky napište:

sudo apt-get install python-pip python-dev python-setuptools python-virtualenv virtualenv git libyaml-dev build-essential

Zajímavé je (pro lidi jako já, kteří neznají python a jeho virtualenv), že po zkompilování všech těch zbytečných věcí není možné výsledný adresář někam přesunout, protože všechny ty blbosti mají v sobě zakompilovanou absolutní cestu. Takže když jsem to zkompiloval na zkoušku v /tmp/OctoPrint-master/, tak už to tam musím pořát mít, i když nechci (protože /tmp/ se po každém restartu promazává). "Vyřešil" jsem to tak, že jsem ten zkompilovaný adresář přejmenoval a přesunul do /home/, a teď si jen vždy před spuštěním udělám symbolický link - nějak takto:

ln -s /home/OctoPrint /tmp/OctoPrint-master

Tím jsem se nechtěl pochlubit, je to takové škrábání se levou rukou za pravým uchem - spíš jsem chtěl jen upozornit na něco, co jsem původně netušil, a že to jde obejít i bez kompletní rekompilace. Počítám, že v diskusi mě nějaký pythonista upozorní, že to jde vyřešit ještě nějak jinak - to jsem zvědav.

OctoPrint máme spouštět v tom adresáři, kde jsme ho zkompilovali, a navíc s parametrem "serve", takže v mém popleteném případě nějak takto:

cd /tmp/OctoPrint-master && ./venv/bin/octoprint serve

V tu chvíli se spustí web server na portu 5000, takže v dobře nakonfigurované síti je možné hned poté otevřít webový prohlížeč na PC/tabletu/mobilu a napsat do něj http://orangepione:5000/

Trošku oříšek může být zařídit spuštění programu hned po startu operačního systému. Zkušený uživatel Debianu by napsal init skript (do /etc/init.d/), případně systemd službu, a nejspíš by přitom využil parametr "daemon" OctoPrintu. Je ale možné i trošku "podvádět" a spustit program přímo z /etc/rc.local, což je skript, který se pouští při startu systému. Jen je potřeba spustit OctoPrint pod správným uživatelem a navíc mu zprostředkovat terminál, tedy jeho emulaci programem screen:

su - ja -c "/usr/bin/screen -dmS octoprint /X/venv/bin/octoprint"

V předchozím řádku je potřeba nahradit "ja" jménem vybraného uživatele a "X" cestou ke zkompilovanému OctoPrintu.

Video streaming

Na Orange Pi s originální kamerkou je zajímavý fakt, že přestože používá ovladač "gc2035" přítomný v Armbianu, tak přesto nefunguje ŽÁDNÝ program pro práci s videem kromě jediného - "motion". Proto drtivá většina návodů na Internetu popisuje konfiguraci programu "motion" - například na cnx-software.com.

Fór je v tom, že motion na tohle není dělaný, resp. je kanónem na vrabce. Motion má totiž hlavně hlídat změny v obraze, zatímco nám by stačilo obyčejný video streaming, jak to umí například program mjpg-streamer.

Kdysi jsem našel vysvětlení, proč ostatní programy nefungují, a zajímavý návod, jak to obejít: zavede se modul "v4l2loopback", který vytvoří virtuální video zařízení, a pak se spustí jednoduchý prográmek nazvaný "vidcopy", který kopíruje data z reálného video zařízení (z kamery) do toho virtuálního, se kterým už poté umí pracovat běžné video programy. Ta stránka už na Internetu neexistuje, ale popsáno je to třeba i na tomto blogu.

Poté je možné například zkompilovat mjpg-streamer (potřebujeme ale jistý fork s doplněným klíčovým parametrem "-u"), který bude brát obraz z virtuálního zařízení a streamovat přes web.

Výsledný skript (nazvaný třeba streaming.sh) na zavedení modulů do kernelu ve správném pořadí a spuštění nezbytných programů je zde:

sudo modprobe gc2035
sleep 2
sudo modprobe vfe_v4l2
sleep 2
sudo modprobe v4l2loopback
sleep 2
SIRKA=1280
VYSKA=720
FPS=5
ROZLISENI=$SIRKA"x"$VYSKA
cd $HOME/streaming
(cd vidcopy && ./vidcopy -w $SIRKA -h $VYSKA -r $FPS -i /dev/video0 -o /dev/video1 -f UYVY &)
sleep 3
cd mjpg-streamer/mjpg-streamer-experimental && ./mjpg_streamer -i "./input_uvc.so -r $ROZLISENI -f $FPS -n -u -d /dev/video1" -o "./output_http.so -w ./www"

Tento skript opět spustíme při startu systému přidáním následujícího řádku do /etc/rc.local:

su - ja -c "/usr/bin/screen -dmS streaming /cesta/k/streaming.sh"

Tím se spustí další web server, tentokrát na portu 8080: http://orangepione:8080/

Konfigurace OctoPrintu

Ještě bych rád zdokumentoval pár drobností, které jsem objevil při počáteční konfiguraci OctoPrintu. Například určitě chceme, aby se hned po startu serveru připojil k tiskárně, protože to trvá asi 20 sekund a kdo má na to čekat. Úvodní nastavení komunikačního portu je "AUTO" a když klikneme na "Connect", tak se připojí. "Auto-connect" po startu serveru ale nefunguje, dokud nezvolíme konkrétní sériový port ("/dev/ttyACM0").

Dále, názvy souborů na kartě se objevují ve zkráceném tvaru (jen prvních šest znaků, pak vlnka a číslo) - tohle je známá, ale stále nevyřešená chyba OctoPrintu. Vzhledem k tomu, že SD kartu už nebudeme potřebovat, to asi nevadí.

Zajímavá je též chyba "pozor, tištěný objekt se nevejde na tiskovou plochu". Je to kvůli tomu, že Průšův Slic3r přidává před samotný tisk jakési "rozcvičení" tiskové hlavy, kdy na samém předním okraji tiskové plochy vyjede asi 5cm proužek plastu. Tento proužek je na souřadnici -3, což OctoPrint správně prohlásí jako mimo tiskovou plochu. Vidím několik způsobů, jak to vyřešit. Přesunout inicializační G kód ze Slic3ru do OctoPrintu, nahlásit jako chybu a prosit Ginu o "opravu" (ignorováním počáteční sekvence), anebo to prostě rovnou ignorovat selským rozumem (když v náhledu vidím, že se na plochu vejde, tak věřím, že to bude OK).

V nastavení "Webcam & timelapse" zadáme URL video streamu, který je: http://orangepione:8080/?action=stream. Timelapse jsem neřešil, takže URL na fotky si v mjpg-streameru najdete sami.

Propojení se Slic3rem

Když Slic3r vygeneruje G kód, tak jak ho dostaneme do Orange Pi? Jedna z možností je přes sdílenou složku na Orange Pi (to bysme si tam ale museli nainstalovat Sambu, NFS nebo použít sshfs či něco podobného). Druhou možností je použít tlačítko "Upload" ve webovém rozhraní a nahrát G kód přes prohlížeč.

To je pořád ale "ruční práce". Přitom existuje fantastická možnost automatizace - Slic3r umí vygenerovaný kód poslat přímo do OctoPrintu! V záložce "Printer Settings" je sekce "OctoPrint upload", kam stačí zadat adresu a port našeho nového tiskového prohlížeče ("orangepione:5000") a pak "API Key", který zkopírujeme z OctoPrintu z nastavení "API". Tím se v hlavní obrazovce Slic3ru objeví nové tlačítko "Send to printer" a svět začne být zase o notný kus automatizovanější :-)

Printoid

OctoPrint se svým webovým rozhraním je bezva na práci v lokální síti, ale pokud člověk vyrazí ven, tak prý tou pravou bombou je mobilní aplikace Printoid. To jsem ještě nestihl vyzkoušet, takže sem případně doplním osobní zkušenosti posléze.

Credits:
Tomáš Vít, můj strážný anděl 3D tisku, mě krom jiného upozornil, že Cura má stejnou integraci jako Slic3r.
Pavel Novotný mě doslova dotlačil k instalaci OctoPrintu slovy "čas strávený instalací se ti tisíckrát vrátí při tisku". Také neustále pěje ódy na Printoid, že šetří mnoho času při ladění tiskových profilů.

Velké digitální měření teplot s čidly DS18B20

Delší dobu jsem nosil v hlavě myšlenku měření teploty na klíčových místech otopné soustavy v mém domě. Kotel s relativně vysokým a hlavně neměnným výkonem plus velké množství vody v podlahovém vytápění (majícím velkou tepelnou setrvačnost) totiž způsobují cyklické přechody mezi stavem "je tu chladno, proč ještě kotel netopí" a stavem "je tu zbytečné horko, proč kotel topil tak moc". Chtěl jsem pochopit, jak vlastně celá ta otopná soustava funguje, protože věřím, že by se její regulace dala značně vylepšit - a na to jsem potřeboval vědět, jak se mění teplota v čase, tedy potřeboval jsem teplotu měřit, trvale zaznamenávat a průběžně zobrazovat.

Už dříve jsem sem tam narazil na informace o digitálním měření teploty, ale nakonec mě rozhýbaly k akci až následující dvě věci - jednoduchý český návod na Teploměr pro PC a levná čidla DS18B20 v mém oblíbeném e-shopu. Měl jsem radost, že jeden kus krásného integrovaného digitálního teplotního čidla s 12bitovou přesností a unikátním 64bitovým identifikačním číslem vyjde z Číny jen na 50 Kč, tak jsem tam začátkem listopadu 2012 objednal hned 4 kusy. A protože jsem chtěl čidla připojit k mému novému serveru, který bohužel nemá žádný sériový port, objednal jsem rovnou v Číně i adaptér z RS232 na USB, abych měl kam převodník pro DS18B20 zapojit (spoiler alert: dobře si ho prohlédněte, protože to je naposledy, co ho vidíte).

Týden před Vánoci zboží konečně dorazilo, ovšem tehdy jsem na něj z pochopitelných důvodů neměl čas. Ke stavbě převodníku pro připojení digitálních čidel na sériový port jsem se tak dostal až na Silvestra, takže jsem to udělal nedočkavě, rychle a bezohledně, starou dobrou metodou vrabčího hnízda tak, aby výsledek pasoval do plastového krytu konektoru Canon.

Při testech vše perfektně fungovalo, tak jsem neváhal připojit všechna 4 čidla naráz - jak vidno, zapojují se jednoduše paralelně - a odečítat teplotu na všech současně, abych se ujistit, že ukazují stejně. A skutečně, kalibraci mají výtečnou, rozdíly v teplotách byly maximálně desetinu stupně Celsia. Dokonce jsem použil i právě koupený teploměr a porovnával naměřené hodnoty čidel s ním, pořád všechno bezvadně sedělo. Byl jsem tedy připraven začít čidla rozmisťovat po domě.

Důležitá poznámka o sběrnicích: tato skvělá čidla mají tři vývody - zem, napájení a jeden vývod datový, který umožňuje obousměrnou komunikaci po speciální jednodrátové ("1-Wire") sběrnici vyvinuté právě pro tato čidla. Takže na propojení čidla (či mnoha čidel) s počítačem stačí tři dráty - napájení, zem a data. Ale výrobci čidel (firmě Dallas) se zdály tři dráty ještě moc, a tak vymyslel tzv. pasivní režim, kdy stačí pouhé dva(!) dráty - čidlo se totiž dokáže napájet z komunikace na datovém vodiči (nabije si v sobě kondenzátor a pak z toho chviličku žije). No a protože se v návodech psalo, že pasivní režim je super a sexy, šel jsem do něj taky a rovnou natáhl z pracovny do sklepa ke kotli jen dva dráty (upřímně řečeno jsem neměl moc na výběr, z nouze jsem použil kablík původně myšlený na přenos zvuku z PC v pracovně do TV v obýváku, ještě než jsem před 8 lety postavil MythTV HTPC přímo v obýváku).

Mechanickou část bych rád přeskočil, protože jsem ji tak trochu nedořešil. Nejdřív jsem si koupil skvělou hliníkovou lepicí pásku, o které jsem se domníval, že povede teplo, a tou jsem čidla přilepil přímo na měděné trubky s otopnou vodou. To se ukázalo nedostatečné - čidla se pod lepicí páskou uvolňovala, ztrácela 100% kontakt a měřené hodnoty se rychle začaly lišit od skutečnosti. Tak jsem to pojistil kovovou sponou (tou na zahradní hadice), kterou jsem ale nedokázal utáhnout dost pevně a zároveň dost šetrně - měl jsem pocit, že při utahování to čidlo rozdrtím. Tohle bych ještě rád nějak vylepšil. Stejně tak jsem nevyřešil rozumně nějaké konektory, takže jsem nakonec čidla napájel na dráty natvrdo. To má své výhody (žádné selhávající kontakty), ale i nevýhody (výměna čidel, přemístění čidel, výměna vodičů - všechno znovu pájet).

Pokojové rozvody k čidlům jsem udělal chytřeji: použil jsem existující ethernetové rozvody - tedy CAT5 kabeláž. Pro čidlo jsem po dlouhém váhání a pročítání zkušeností jiných vybral vodiče č. 4 a 5 (modrý a modrobílý), které jsou v normální počítačové síti nepoužité a zároveň jsou spolu hezky zkroucené (takže jsem si říkal, že sběrnice bude odolná vůči případnému okolnímu elektromagnetickému rušení). Čidla jsem nacvakl přímo do RJ45 konektoru a zastrčil do ethernetové zásuvky. Tím můžu měřicí bod jednoduše stěhovat po celém domě, kdekoliv je existující rozvod LAN...

Záhy jsem rozmístil všechna 4 čidla (voda do topení, voda z topení, voda z kotle a vzduch v obýváku), měření fungovalo skvěle, grafy ukazovaly nečekané souvislosti, bylo to úchvatné. Zachtělo se mi měřit ještě víc a tak jsem začal shánět další čidla. Velmi překvapivě jsem našel DS18B20 v místním obchůdku fy Official a to za ještě lepší cenu než v Číně - pouhých 37 korun!

Nakoupil jsem jich další hromádku, k tomu relé na 230V a začal plánovat, že počítač převezme úlohu termostatu v obýváku, který dnes řídí topení kotle pouze podle teploty vzduchu. Jistě dokážu naprogramovat dramaticky účinný a nesmírně inteligentní software, který bude řídit kotel tak skvěle, že doma nebude ani zima ani horko!

Na dobrou regulaci vytápění by se ale opravdu hodilo znát venkovní teplotu (abych tak trochu zapojil i ekvitermní regulaci), takže jsem protáhl 1-Wire sběrnici o dalších pár metrů ze sklepa až ven na stěnu domu a tam přidal další čidlo. Zároveň jsem natáhl další větev sběrnice doma a kromě obýváku začal měřit teplotu i v horním patře, protože obývák má největší solární zisk ze všech místností a to velmi často doplete regulaci kotle, který pak netopí, protože celý den svítilo Slunce.

A v tom se to celé po..kazilo. Teplotu měřím každou minutu a grafy zobrazuji za posledních 12 hodin, 48 hodin, a celý týden. A naráz začalo být nepřehlédnutelné, že software Digitemp občas vyčte z čidel naprostý nesmysl. Postupně jsem se pokoušel ty nejviditelnější hrubky odstraňovat - například "127,94" stupňů Celsia jsem brzy vyhodnotil jako chybu čtení, kdy z čidla soft vyčte jen 12 binárních jedniček. Stejně tak jsem brzy začal z grafu vynechávat hodnotu "85,0", o které jsem se dočetl, že přímo značí Error, tedy chybu čtení čidla.

Bohužel i přes tyto úpravy se pořád množily chyby, kdy teplota na některém čidlu v naprosto náhodné momenty "ustřelila" třeba o padesát stupňů Celsia jedním či druhým směrem, ačkoliv při dalším čtení o minutu později už bylo vše opět v pořádku. Tyto chyby měly také tendenci se akumulovat, kolikrát když se objevily, tak se pak objevovaly pořád, množily se a někdy pomohl až restart PC (?!). Jindy zase zmizely po několika hodinách samy. Byla to noční můra a pokusům a ladění jsem věnoval nesmírné množství energie a času. Podle tohoto by opravdu nešlo řídit kotel...

Začal jsem cíleně hledat další podobné nešťastníky na Internetu a brzy jsem našel celou řadu materiálů, ze kterých poměrně jednoznačně plynulo, že použití pasivního módu (tedy jen dvou drátů k čidlům) je naprosto hloupé a funguje to v podstatě jen náhodou a jen na velmi krátkých (desítky centimetrů) sběrnicích s jen pár čidly. Jenže já už v té době měl mohutně rozvětvenou síť čítající jistě desítky metrů nejméně třemi směry, a 8 čidel online. Aha, takže takto velké sběrnice nemohou v pasivním módu fungovat kvůli odporu a kapacitě vedení. Ach jo! Naštěstí nešťastníci měli několik tipů na řešení, které jsem postupně vyzkoušel:

1) pro 1-Wire sběrnici použít kroucenou dvoulinku, protože ta eliminuje rušení, co se může po cestě indukovat. Takže jsem pracně přepájel celé vedení ve sklepě od čidla k čidlu. Výsledná změna žádná, nebo možná dokonce k horšímu. Hledal jsem tedy dál a pak jsem se dočetl, že problém způsobuje kapacitance dlouhého vedení, která v podstatě "zaoblí" hrany digitálního signálu tak moc, že se stane nečitelným. Takže chyba, zpět na stromy!

2) pro 1-Wire sběrnici použít NEkroucenou dvoulinku, protože má menší kapacitanci. Opět jsem pracně přepájel celé vedení ve sklepě. Neměl jsem sílu předělat čidla nacvaknutá v RJ45 konektorech, takže jsem místo toho vypojil domácí měření úplně. Sběrnice se tím dramaticky zjednodušila a chyb čtení opravdu výrazně ubylo. Ovšem jak regulovat topení bez vnitřní teploty? Hledal jsem tedy další tipy a našel...

3) přidat kondenzátor před čidla. To se mi zdálo divné, vždyť jinde vysvětlovali, že to přestává fungovat právě proto, že dlouhá sběrnice už má příliš velkou kapacitanci, no ale zkusil jsem přidat kondenzátor tuším 22nF k nejvzdálenějšímu čidlu. Sběrnice totálně vytuhla, takže tudy ne.

4) No a poslední tip, který jsem našel, bylo přidat rychlou diodu v závěrném směru před každé čidlo (to myslím doporučuje sám autor Digitempu). Prý to ořeže nějaké zlé napěťové špičky na sběrnici nebo co. Koupil jsem tedy 8 Schottky diod a postupně je začal dávat paralelně k nejvzdálenějším čidlům. To se mi zdálo, že zabralo, ale spíš jsem měl jen štěstí na několikadenní klid před bouří, neboť chyby na sběrnici se (zřejmě po zapojení jedné domácí větve ke sběrnici) opět vrátily...

Začátkem února jsem se po stovkách pokusů dostal do stavu, že pokud jsem odpojil dvě domácí větve zapojené přes CAT5 a nechal jen větev sklepní, tak to fungovalo téměř bez chyb, ale jakmile jsem sběrnici zapojil "do hvězdy", chybové byly i desítky procent ze všech měření. Bylo to bohužel v souladu s tím, co jsem se nakonec dočetl o pasivních 1-Wire sběrnicích na webu, kde jasně doporučují žádné zbytečné odbočky či dokonce rozbočky a celou 1-Wire sběrnici jen jako jeden (nepříliš dlouhý) drát.

Už to peklo nebudu dál protahovat. Po mnoha týdnech v podstatě marných bojů jsem při pročítání dalších a dalších zdrojů informací o 1-Wire sběrnicích a neustálém narážení na zmínky o tom, že pokud chceme mít čidla připojená k Arduinu přes pasivní sběrnici, rozhodně musíme přidat rezistor 4k7 mezi zdroj napětí a tu sběrnici (kterým se sběrnice takto de-fakto "napájí"), mě napadlo zkusit takové napájení sběrnice přidat i na ten můj převodník. Tipoval jsem, že tam sice něco takového bylo původně myšleno i u tohoto převodníku pro DS18B20 na RS232 (zřejmě to má brát energii z DTR), ale třeba je tam "málo šťávy?".

Tak jsem udělal naprosto krutý HW hack: vzal jsem stavebnici "Logitronic 02" (krásné dětství, dnes bezostyšně zkopírováno v stavebnicích Voltík), vrazil do ní 4xAA nabíjecí NiMH články (= 5V, jak se pro TTL hodí) a přes potenciometr nastavený na zhruba 4kOhm připojil k mé 1-Wire sběrnici. A světe div se - všechny ty proklaté chyby, které mě dva měsíce zoufale trápily, naráz zmizely! 3.března jsem otevíral šampáňo...

Zřejmě jsem ta čidla na sběrnici měl skutečně napěťově "podvyživená", proto všechny ty chyby čtení, kdy čidla neměla dost energie dokončit datový přenos. V té době jsem už začínal podezřívat použitý USB-RS232 adaptér, a tady se mi to potvrdilo. Stačilo na zkoušku přepojit 1-Wire převodník do PC s reálným RS232 portem a teploty byly také bez chyb, i bez dodatečného napájení (proč mě tohle nenapadlo ani jednou za poslední dva měsíce trápení?!). Loni jsem koupil dva ty USB-RS232 adaptéry, jeden na toto měření teplot, druhý na připojení UPS, a oba zklamaly obrovským způsobem, po vyčerpávajícím hledání chyb všude jinde.

Výborná zpráva je, že i ta moje docela hustě rozvětvená a velmi dlouhá pasivní 1-Wire sběrnice s kroucenou dvoulinkou naráz začala fungovat dobře. Bedlivě jsem ji sledoval a čekal na moment, kdy selže, ale nic takového se nestalo, šlapala poctivě po další týdny a naměřila stovky tisíc měření bez jediné chyby! Takže všechny ty negativní články a špatné zkušenosti byly možná způsobené taky podobnou napěťovou podvýživou. Pokud je pasivní 1-Wire poctivě "napájen", vydrží zjevně hodně, rozhodně víc, než se píše na webu. Koncem února, v nejhorší situaci, jsem už byl psychicky připravený celé to předrátovat a předělat sběrnici na třívodičovou, ale teď si říkám, že to asi vydrží tak, jak to je.

Nakonec se vybily ty akumulátory držící 1-Wire sběrnici nad vodou a při následném pokusu napájet ji přímo z USB jiného počítače jsem zřejmě popravil ten USB-RS232 adaptér (čehož ovšem vůbec nelituji, protože ten si stejně nic jiného nezasloužil!). V té době jsem už byl pevně rozhodnutý postavit nový ďábelský počítačový termostat využívající tuto mohutnou síť teplotních čidel, ale ne na bázi PC, které nemá žádný rozumný výstupní port pro ovládání relé (ano, bohužel, paralelní port u mého "serveru" taky chybí), ale na bázi pro mě zcela nového světa - Arduina.

Doplnění: po téměř dvou letech má tento článek své pokračování zde.

USB-RS232 adaptér a UPS

Postavil jsem si nový server z nepoužívaného nettopu Acer Aspire Revo (o tom někdy jindy, je to dost netypické provedení), který nemá ani jeden sériový (RS232) port, ale za to má 6 USB portů. A tak jsem se začal poohlížet po nějakém levném převodníku z USB na RS232. Záhy jsem našel opravdu pěkný kousek na DX.com za nějakých 60 Kč, v recenzích se dočetl o bezvadné Linuxové kompatibilitě, tak jsem neváhal a šel do něj.

Adaptér skutečně v Linuxu perfektně funguje, přihlásí se jako pl2303, kernel si sám natáhne správný modul, který udělá /dev/ttyUSB0 a je připraven k použití. Nějakou dobu jsem ho nechal ležet ladem, než mě napadlo využít ho pro propojení UPS se serverem tak, aby server věděl, kdy je na baterkách. Mám pořád svou starou, větrem ošlehanou, věčně vrčící a nic nevydržící Blackout Buster 400 UPS od Power Kinetics, ke které jsem před pěti lety opravil řídící soft a která má jen RS232 konektor.

Tentokrát jsem na to ale chtěl jít mnohem fikaněji. Dočetl jsem se, že NUT už tuto UPS podporuje a tak jsem začal rovnou s ním, abych mohl později nainstalovat NUT monitor na pracovní PC, připojené na stejnou UPS. NUT má spoustu konfiguračních souborů, tak jsem všechno nastavil dle svého nejlepšího vědomí a... nic nefungovalo. Dost dlouho jsem to ladil, než jsem pojal jisté podezření a zároveň jsem vyměkl natolik, že jsem se rozhodl nejdřív oprášit původně fungující konfiguraci a pak jít dál po jednotlivých menších krocích.

Začal jsem tím, že jsem UPS připojil k pracovnímu PC přes RS232 (kde vždycky bývala) a zároveň použil starý dobrý OpenUPSmart. Vše fungovalo bezvadně. OK. Tak jsem nahradil OpenUPSmart NUTem a zkusil znovu. Stále vše fungovalo výborně. Takže jsem přepojil UPS přes USB-RS232 adaptér do USB portu, a to už nefungovalo. Tak jsem zkusil jiný USB port a ten fungoval... ovšem za minutu hlásil ztrátu spojení s UPS. Chvíli jsem čaroval s linuxovým jádrem (odpojit adaptér, odstranit modul pl232, znovu zapojit adaptér, povolit debug hlášky v kernelu, ...) a pak zas spustil NUT a ten zas chviličku fungoval a pak zas ztráta spojení s UPS. Nakonec už jsem byl schopen to nasimulovat spolehlivě - komunikace s UPS fungovala jen asi prvních 80 sekund po zavedení modulu, pak se jakoby něco "vybilo" a spojení se ztratilo.

Teprve teď mě napadlo přečíst si ty recenze na DX.com pořádně a tam jsem se dočetl věci, které ledacos vysvětlovaly. Zdá se, že tento adaptér je výborný na komunikaci s běžným RS232 zařízením přes RX+TX, kde normě vyhoví, ale není úplně OK na takové to "mávání" jednotlivým signálovými dráty (které UPS rády používají místo normální komunikace), nehledě k tomu, že nejspíš neumí dávat plných 12V, na což může být některý protějšek (jako tahle UPS) trošku citlivý.

Závěr je, že tento bezva adaptér je na prodej za 60, a já teď sháním novou UPS s USB komunikací...

ASUS M2N VM-DH: uspat a probudit se

Před lety jsem si koupil základní desku do počítače od firmy ASUS, jmenovala se (vlastně ještě pořád se jmenuje, pořád slouží) M2N VM-DH. To DH značí Digital Home a to mě na ní fascinovalo - měla vestavěnou na tehdejší dobu výkonnou grafiku nVIDIA 6150, WiFi a hlavně jako příslušenství měla infračervené dálkové ovládání, které dokonce umělo počítač zapnout z vypnutého stavu! Čili to vypadalo jako skvělý základ pro multimediální stroj (v té době jsem teprve začínal koketovat s představou něčeho, co časem vykrystalizovalo v MythTV).

Ačkoliv v MS Windows se tato deska (resp. počítač na ní postavený) uměla usnout (suspend) a zase se probudit v pořádku, tak v Linuxu se mi to NIKDY nepodařilo. Za celé dlouhé roky, kdy jsem to trápil v různých verzích linuxového kernelu i distribucí, se nikdy neprobudila v pořádku, tj. vždycky buďto vytuhla při probouzení, nebo alespoň byl nefunkční obraz (černá tma, monitor nedetekoval signál). Zkoušel jsem všechny možné triky, ale nikdy jsem to neporazil.

Nedávno jsem si usmyslel, že když je problém po probuzení v grafice, tak ta on-board grafika asi stojí za starou bačkoru a pořídil jsem si výkonnou přídavnou grafiku nVIDIA 210 do PCI-E slotu. Všechno jelo dobře, jen probouzení z uspání se stále nedařilo. Nepomohl ani nejposlednější update BIOSu. Zlomil jsem nad tím hůl.

Teď jsem se ale rozhodl pro akci Kulový blesk, spočívající ve velké rošádě domácích počítačů. Jedním z cílů akce je postavit samostatný MythTV backend a umístit ho někam mimo obytné místnosti, jelikož hluk z Tenoru se mi nikdy nepodařilo zcela odstranit a jak větráky stárnou, a harddisky v MythTV stroji přibývají, hladina hučení/šumění/občas_vrzání se v obýváku pořád zvyšuje a je potřeba s tím už rázně zatočit. Potřebuju tedy postavit samostatný server, ale z čeho?

Opět jsem si vzpomněl na svůj pracovní stroj, který by díky integrované grafice byl skvělý základ pro server hučící někde ve sklepě. Dal jsem mu znovu šanci a snad podesáté ho začal cvičit na uspávání a probouzení. Vzdal jsem probouzení s obrazem - u serveru stejně nebude potřeba, a jal se ho cvičit alespoň na obyčejné, ale spolehlivé probuzení z uspání do paměti, a to magickým paketem poslaným po ethernetové síti.

V nainstalovaném Ubuntu 10.10 se nedařilo vůbec - při probouzení vytuhl celý kernel. V aktuálním Debianu 6.0 jsem probudit mohl, ale pouze tlačítkem Power na skříni - klávesnicí ani po síti se nedařilo. Navíc šlo probudit stroj jen jednou, podruhé už to nešlo, skript pm-suspend zůstal už při uspávání někde viset. Ve starším (ale stále báječném) Debianu 5.0 probouzení tlačítkem Power fungovalo spolehlivě - samozřejmě stále bez obrazu, ale na ten už jsem rezignoval. Bohužel pro nový MythTV 0.24 potřebuji nový Debian 6.0 s nejnovějším Qt... Jak tohle vyřeším? Starý kernel v novém Debianu? To nevypadá dobře...

Dost zoufalý jsem se jal hledat, jak je to s tím probouzením ve světě. Zlatý Google nezklamal a našel nějakého panáčka, který právě tuhle desku naučil uspávat a probouzet se tím, že v BIOSu popadl nastavení "Plug and Play OS installed" a VYPL HO! Velmi nadějná stopa! Ovšem jak ironické - tato volba je v BIOSu kvůli MS Windows 95 (první plug&play OS od Microsoftu), Linux je už mnoho let (někdy od verze 2.4) samozřejmě také plug&play. Nicméně právě tato deska tu volbu pro Linux zjevně potřebuje vypnout - nejspíš ty integrované periférie neumí kernel dodneška pořádně zinicializovat... Nadšeně jsem přenastavil BIOS a zopakoval uspávací triatlon, bohužel bez úspěchu - Ubuntu tuhé rovnou, Debiany se chovaly stejně jako dříve. Jak dál s tím serverem tedy?

Dnes ráno jsem se rozhodl konat i přes stávající nejistotu a začal tím, že jsem vyndal z počítače přídavnou grafiku. Tím jsem ho ale rozlobil natolik, až jsem ztratil obraz i na integrované grafice. Když jsem to zkoumal, zjistil jsem, že ta integrovaná grafika už je tak naštvaná, že vůbec nemluví s novým monitorem přes VESA DDC protokol, nic o něm neví, nezná jeho nádherné Full HD rozlišení, zkouší na něj VGA 640x480, monitor se urazí a obraz není žádný. Musel jsem na ni pořádně kleknout, aby se umoudřila - přes vrácenou externí grafiku jsem z monitoru vymáčkl EDID data, uložil do souboru, /etc/X11/xorg.conf instruoval tak, aby integrovaná grafika načetla EDID data ze souboru, tím pochopila, jak krásný monitor je připojený a tak jsem konečně získal zas normální obraz.

To mě velmi povzbudilo a začal jsem znovu, pojedenácté, zkoušet to uspávání. V nainstalovaném Ubuntu 10.10 jsem do /proc/acpi/wakeup jsem jen tak z voleje naechoval "PS2K", na příkazové řádce zadal "sync; sync; pm-suspend", pomodlil se k bohům výpočetní techniky a odpálil to celé Enterem. Počítač okamžitě usnul, tak jsem vydržel chvíli bez dechu a pak jsem jemně klepl do mezerníku klávesnice - a voilá, počítač se probudil i s obrazem!!! Naprosto neuvěřitelný úspěch po letech beznaděje! Přičemž vlastně vůbec nechápu, co se změnilo oproti minulým pokusům - aha, snad jen to nastavení v BIOSu, Plug&Play OS. Nicméně to jsem přece zkoušel už jednou a nepomohlo to, možná souběh s tou přídavnou grafikou? Nevím, neřeším, nepřepínám a jedu!

Pln euforie jsem zkusil ještě jednu drobnost: naechovat MMAC do wakeup, jestli to náhodou nevyřeší probouzení po síti, když ten PS2K vyřešil probouzení klávesnicí. A fakt, počítač se probudil i magickým paketem jako by se nechumelilo!

Souhrn kroků vedoucích k vysněnému cíli:
1) v BIOSu musí být volba "Plug&Play OS installed: NO"
2) integrovaná grafika musí být v dobré náladě, xorg.conf odkazovat na správná EDID data
3) "echo PS2K > /proc/acpi/wakeup" pro probouzení klávesnicí
4) "echo MMAC > /proc/acpi/wakeup" pro probouzení Wake-on-LAN paketem po síti
5) "sync; sync; pm-suspend", pomodlit a jede to! (v Ubuntu 10.10, Debiany jdu teprve zkusit)

Jsem opojen vítězstvím nad hmotou a nenávistí a kola velkého Kulového blesku se roztáčejí...

Seriál o MythTV v češtině

Na vydařené loňské konferenci LinuxAlt v Brně jsem se potkal s šéfredaktorem webzinu Root.cz Petrem Krčmářem, což je mimochodem velmi pohodový chlapík, a zeptal jsem se ho, neměl-li by zájem o článek o projektu MythTV. Jak se tak pěkně česky říká "slovo dalo slovo", Petr neměl nic proti, já mu to slíbil a týdny běžely.

Konečně přes Vánoce jsem měl trochu času a tak jsem sedl a začal psát. A napsal jsem článek o MythTV, ale byl moc dlouhý - prý má mít článek pro Root.cz tak 6 až 9 tisíc znaků. A můj měl 15 tisíc. Tak jsem ho rozdělil na dva články a tam někde to začalo. Právě teď mi tam vychází už čtvrtý díl seriálu o MythTV aneb linuxu v obýváku.

Je to dobré. MythTV mi hodně dal, Root.cz jakbysmet, a tohle je můj způsob, jak to oběma aspoň trochu oplatit.

Pokus o organizaci fotek dle EXIF

Nenacházím slušné slovo popisující stav, v jakém mám své digitální fotografie. Hmm, nejbližší z těch publikovatelných je asi entropie, nebo možná spíš anarchie? V minulosti již proběhly pokusy situaci zvládnout - nejdříve snad příhodným pojmenováváním adresářů, později dokonce importem fotek z aparátu přímo do F-Spotu (který má svou databázi a umožňuje fotografie opatřit tagy - ale pak se s nimi dá dál pracovat už jen v něm - běda, jak je člověk přemístí jinam!). Nedávno jsem dokonce nainstaloval Picasu pro linux, ale ještě jsem ji neměl čas ovládnout.

Dnes jsem se proto rozhodl jít cestou drobných, inkrementálních změn a nenápadnou evolucí se dopracovat k lepšímu stavu správy fotografií. Pro začátek jsem se rozhodl všechny ty tisíce souborů přejmenovat tak, aby měly stejnou velikost písmen (třeba velkou) - aby se vůbec daly dohledat a vyřadit duplikáty (protože různé způsoby kopírování či importování fotek různě volily konverzi velikosti písmen z FAT foťáku na ext3 linuxu).

Pro hromadné přejmenovávání souborů jsem v práci vyvinul nějaké bash skripty, ale dnes na mě padla lenost a tak jsem se jal vyhledávat v seznamu balíků pro Ubuntu. Napotřetí jsem vybral GPRename, který v přehledném GUI dovolí vybrat plánovanou změnu názvu souboru (z mnoha možností) a pak i předvede, co se z daného výběru souborů přejmenuje a jak (Preview). Dost dobré.

Takže názvy souborů jsou OK, a teď by to chtělo spravit datumy. Nejlépe samozřejmě tak, aby datum souboru odpovídalo datu vytvoření fotky. Na to jsem odhadem nainstaloval balíček ExifTags, který obsahuje šikovný prográmek intuitivně nazvaný "exiftime". Ten umí čarovat s datem a časem uloženým v EXIF hlavičce JPEG souboru fotky.

Ačkoliv "exiftime" umí krom jiného i opravit čas vytvoření fotky podle času souboru, tak opačná funkčnost mu chybí. Jakmile jsem zjistil, že výstup (časovou informaci) z "exiftime" nepůjde použít v příkazu "touch" bez parsování, začal jsem dumat, jak to naprogramovat - ale pak opět zvítězila lenost a strýček Google mi obratem našel několik možností, z nichž jsem narychlo vybral exif_touch-0.2.tar.gz. Je to jednoduchý perlový skript, který dělá přesně to, co se mi dnes nechtělo skriptovat - opravuje datum a čas souboru podle údajů uložených v EXIF datech fotky...

V další fázi se zřejmě zaměřím na zrušení všech duplikátů (s čímž mi snad pomůže FSlint) a rozdělení té masy fotek dle data do nějak chytře nazvaných adresářů. Nakonec se ale stejně nevyhnu nějakému tagování... na to ale chci nejdříve prostudovat, jestli bude stačit ukládat tagy do poznámek v Exif datech, nebo jestli mě situace donutí poklesnout k nějaké externí databázi (a dostat se zpět tam, kde se mi s F-Spotem nelíbilo).

M2N-SLI DELUXE BIOS 1701 nebrat!

Po posledním pokusu vyladit počítač v obýváku se tu mrtvolu po upgrade na verzi BIOSu 1701 podařilo naštěstí oživit pouhým vytažením baterie a resetováním CMOS. Po chvíli ladění se BIOS "usadil" a vše vypadlo OK, tak jsem rozradostněný upgradoval RAM z DDR-400 na DDR-800 (1840 MB/s -> 2500 MB/s dle memtest86 2.11) a chystal se vyzkoušet, o kolik lépe to teď pojede.

Ale ouha - linux na tom stroji vůbec nechtěl fungovat! Zatímco Debian kernel 2.6.24 dokázal i přes totální stávkování SATA rozhraní trochu nabootovat a dokonce nahrál první minutu Večerníčku, než se to celé zaseklo, tak Ubuntu kernel 2.6.28 vytuhl už během bootu a z hlášek bylo zřejmé, že do paměti se z disku načítají úplné nesmysly.

Zkusil jsem tedy Ubuntu 9.04 z USB klíčenky, abych ochránil disky od nejhoršího, ale to vytuhlo uprostřed bootování. Znovu jsem otestoval RAM, vše OK. Chystal jsem se začít kontrolovat SATA kabeláž, ale pak mi to nedalo a rozhodl jsem se nejdříve vrátit na původní BIOS verzi 1102. Ta je kupodivu na webu ASUSu označená jako "beta" a hlavně ji můj aktuální EZ-Flash odmítl nainstalovat, asi že je pro něj moc stará. Stáhl jsem tedy všechny dostupné verze BIOSů (130x, 140x, 150x) a chystal se postupně downgradovat až na moji původní funkční verzi...

Nakonec se ukázalo, že ihned po nainstalování verze 1501 se počítač krásně rozběhl, a vše začalo fungovat jak mělo. Takže tu máte důkaz místo slibů - BIOS update verze 1701 je vadný, neinstalovat!

HTPC tuning

Tak mi to zas včera v hluboké noci nedalo (mívám takové "záchvaty" tak co půl roku) a jal jsem se ladit počítač v obýváku k vyšším výkonům. Impulzem byla tentokrát zřejmě TV Nova v HDTV, kterou CS Link včera slavnostně dotlačil na orbit hned vedle jiné stejné TV Nova taky v HDTV, co ji tam už rok vysílá Sky Link (CS Link a Sky Link jsou dva čeští satelitní operátoři, kteří nejsou schopní se domluvit na sdílení společných nákladů). Ani TV Nova v 1080i, ani HD-DVD/BluRay ripy v 1080p mi bohužel nejedou plynule, procesor na 2700 MHz prostě MPEG-4 AVC nestíhá dekódovat a potřeboval by trošku pomoci.

Začal jsem jako obvykle s VDPAU, a jako obvykle ihned pohořel na obřím overscanu. Takže už jsem zkoušel GF8400, GF9500 a nejnověji GF9400 a stále bez úspěchu (podrobněji popíšu v zvláštním článku). Pak mě přepadla popůlnoční ospalost a musel jsem se vzdát dalších kroků...

Dnes mě pro změnu napadlo podívat se na zoubek pomalosti operační paměti - koupil jsem DDR2-800, ale jede jen na 400 MHz (to dle BIOSu, zatímco memtest86 píše jen 208 MHz), tedy pouhou poloviční rychlostí. Kamarád i Google poradili BIOS update, tak jsem pro svůj M2N-SLI DELUXE motherboard s původní, již značně obstarožní verzí 1102 (z 20.6.2007) hbitě stáhl a přes pohodlný ASUS EZ-Flash napálil nejnovější verzi 1701 (někdy z října 2008).

Těžko vyjádřit mé překvapení, když po rebootu stroj nahlásil, že BIOS byl změněn a doporučuje zajít do nastavení a vše zkontrolovat, a hned potom totálně vytuhl. Takovému závěru říká Krakonoš lakonicky "Kdo chce mít moc, nemívá nakonec nic...". Ale tohle byl přece jen obyčejný upgrade BIOSu?? Ještě nikdy se mi to nestalo, tak jsem se zeptal strýčka Googla, co na to říká - a světe div se - nebyl jsem zdaleka první, co s verzí 1701 takto pohořel... Proč jen jsem se nezeptal předtím? A proč ASUS vystavuje takovou "bombu" na svém webu?

Zajímavé je, že se z této situace (hantýrkou nazývané "bricked", nebo-li počítač se proměnil v bezcenné těžítko alias cihlu) se nedá nijak rozumně vybruslit. Nepomůže prý ani vymazání CMOS paměti, ani slavný ASUS CrashFree BIOS, kterým se má teoreticky poškozený BIOS sám z CD opravit. Jen snad "jedna paní povídala", že pokud se motherboard kompletně odstrojí a hlavně se vyndá PCI-E grafika a vrazí stará PCI (kde ji budu proboha v dnešní době shánět? :-), tak že potom to s vytaženou baterkou a nepřetržitě nulovanou CMOS možná nabootuje...

Správa hesel

V jeden týden se mi sešly hned tři žádosti o pomoc, které mě přiměly zamyslet se nad hesly, jejich bezpečností a správou. Nejdříve se ozval hned vedlejší soused, v neděli odpoledne, že naléhavě potřebuje, abych na 5 minut přišel. Už znám tyhle "pětiminutovky", takže jsem si nekazil krásné nedělní odpoledne s milou návštěvou a zašel k němu až o půl deváté večer, kdy jsem měl konečně chvilku čas.

Netušil jsem, o co jde, dokud přede mnou neotevřel notebook s WinXP přihlašovací obrazovkou a neřekl provinilým hlasem: "zkoušel jsem si zabezpečit počítač a teď se nemůžu přihlásit". Postupně z něj lezlo jako z chlupaté deky, že uklízel uživatelské účty a některé, co nepoužívá, označil jako zamčené - ale že asi nějakým omylem označil jako zamčený i svůj vlastní, a když se odhlásil, tak už se nemohl přihlásit zpět. A heslo Administrátora neznal, koupil notebook s nainstalovanými WindowsXP, ale heslo k němu nedostal. Tak jsem mu řekl, že si jdu domů pro nářadí a odběhl jsem k sobě.

Doma jsem automaticky stáhl nejnovější beta verzi univerzálního záchranného nástroje UBCD (aktuálně 5.0b12), přesvědčil se v seznamu změn, že tam je nejnovější verze Password Editoru, vypálil na poslední CD-RW, co jsem doma našel, a přeběhl zpět k sousedovi. Ten si naštěstí pamatoval heslo do BIOSu, takže jsme nastavili boot z CD-ROM a nabootovali UBCD.

O 10 minut později jsem si byl už jistý, že ten Password Editor tam prostě nenajdu. Ta verze 5.0 vypadá jinak než klasická 4.x a i když jsem proběhl všechny nabídky a dokonce skončil v DOSu, Volkov Commanderu a prošel znovu všechny dostupné příkazy, tak jsem nic na hesla nenašel. I řekl jsem sousedovi, že se jdu k sobě domů podívat na internet, kde to vlastně je, a odběhl jsem opět k sobě.

Tam jsem tentokrát stáhl boot CD přímo od autora toho Password Editoru, chvíli marně hledal CD-RW, ale protože se mi nechtělo běžet zase k sousedovi (už potřetí) jen pro CD, tak jsem nakonec vytrhl jedno zapomenuté v autorádiu, obětoval MP3 a vypálil ten editor. Opět přeběh k sousedovi, boot, vynulovat heslo Administrátora, uložit, restart... A nic, Administrátor se stále nemohl přihlásit. No nic, tak zpět do Password Editoru, a hle - účet Administrátor byl taky zamčený! :-) Takže jsem už nezaváhal, odemkl všechny účty a vynuloval všechna hesla, znovu uložil, restart a konečně úspěch. Za slabou hodinku jsem to měl :-) Poučení: když neznáš heslo Administrátora, nepouštěj se do úklidu účtů a hesel. A pro "uklidnění": dej si heslo do Windows XP jak skvělé/tajné/dlouhé/neprůstřelné chceš, stejně jde jednoduše změnit, když někdo nastartuje počítač z CD.

Další případ byl trošku jiný, ale stále o heslech: volal mi člověk, že ho jeho VoIP telefonní operátor tak dlouho přemlouval, ať si změní své heslo k svému účtu na webovém rozhraní u operátora (kde je billing, výpisy telefonních hovorů a další důvěrné údaje, což by jistě mělo být zabezpečeno dobrým heslem), až podlehl a heslo si změnil. V tu chvíli se mu ovšem odmlčel telefon, protože VoIP adaptér používá stejné heslo pro autentikaci na SIP serveru. A to on si změnit neuměl, Sipuru jsem mu kdysi nastavil já a on od té doby neměl zapotřebí do ní chodit, ani nevěděl kudy a jak.

Tak jsem přišel, seznámil se s novou topologií jeho domácí LAN (dva routery, dvojitý NAT, dva DHCP servery) a pokusně začal hledat IP adresu Sipury (litujíc, že jsem si nevzal nějaké živé Linux CD , protože nmap by to našel raz-dva). Se štěstím jsem to napotřetí trefil, v rozhraní pak už rychle našel a nastavil heslo a tentokrát bylo za pět minut hotovo - telefon opět fungoval. Poučení z toho nejspíš je, že změna hesla účtu se musí provést až po zamyšlení, kdo všechno se ještě ke stejnému účtu může přihlašovat, a změnit všechna tato hesla na všech počítačích/zařízeních zároveň.

Třetí případ se táhl už déle, jednalo se o Pidginy v Ubuntu 8.04 LTS, které se z ničeho nic přestaly hlásit k českému Jabber serveru. Věděl jsem, že ICQ měnilo protokol a to si vynutilo upgrade Pidginů, ale netušil jsem, jak to může souviset s nefunkčností Jabbera. Osobně jsem nic nezaznamenal, možná proto,že doma už mám všude Ubuntu 8.10, anebo ještě spíš proto, že jsem nedávno přešel na Gajim.

Po upgrade na poslední verzi Pidgina (2.5.5) se k účtům pořád nemohli přihlásit, tak jsem je nechal vyzkoušet si, jestli jim ještě fungují jejich účty, na webovém Jabbim klientu. Účty i hesla jim fungovaly, tak jsem ještě chvíli pátral na špatných místech, než jsem je přiměl znovu zadat do Pidgina hesla, která údajně už roky neměnili ani tam, ani jinde. A to skutečně pomohlo a všechno začalo zase fungovat. Nevím přesně, kde mohl být problém, ale moje hypotéza je, že některý z ICQ vynucených upgradů Pidgina ve stabilní řadě Ubuntu 8.04 (LTS!) změnil formát uložení hesla a tím stará hesla zneplatnil. Když jsem je ovšem viděl si ta hesla rozpomínat, jak si to navzájem připomínali slovy "to je to tvoje jediné heslo, máš ho všude stejné", zamyslel jsem se nad svým přístupem k heslům.

Samozřejmě ctím, že není správné/bezpečné mít jedno heslo na přihlašování všude, takže jsem používal na důležité věci silná hesla, a na nedůležitá jedno stabilní heslo. Postupně, jak jsem se hlásil do více a více webových služeb, tak jsem kvůli bezpečnosti začal vymýšlet nová hesla i pro relativně nedůležité věci, ale jejich správu (tj. hlavně zapamatování) jsem nechávám plně na správci hesel ve Firefoxu (primárním browseru). Bohužel se ovšem při jednom upgrade Firefoxu (odhadem tak mezi verzemi 3.02 - 3.04) stalo, že kvůli chybičce na chvíli znepřístupnil všechna zapamatovaná hesla. A v tu chvíli se ukázalo, jak moc jsem na něj spoléhal a kolik hesel jsem si vlastně už nepamatoval!

Po této zkušenosti jsem se definitivně rozhodl, že si hesla začnu psát někam na (elektronický) papír. A kupodivu jsme jich shromáždil už poměrně dost - prozatím jsem si jich vzpomněl či znovuzaložil 26 (většinou jsou to různá webová fóra či webové účty k určitým službám), a je otázkou, kolik jsem si jich ani nevzpomněl, ale zatím nepotřeboval.

Takže pro mě momentálně platí, že přihlašovací údaje by sice měly být různé (ideálně pro každý web jiné heslo), ale rozhodně někde poznačené, protože jinak si už se svou rychle se obnovující pamětí ani neškrtnu... A teď se ukáže, za jak dlouho se budu muset dobývat do počítače sám sobě! :-)

ASUS out, D-Link in

Už jsem měl fakt plné zuby těch problémů s ASUS WL-500gP, který naprosto náhodně přestával vysílat WiFi signál, tak jsem si koupil naopak to nejlevnější, co je k dispozici - D-Link DIR-300. Pár dnů fungoval celkem OK (i když s drobnými výpadky), ale poté, co se mu včera odmlčel WiFi signál, tak jsem nezaváhal a nasypal do něj DD-WRT firmware.

Musím napsat, že je to úžasné. Detailní webová konfigurace, spousty skvělých věcí, SSH, Wake-On-Lan, VPN, různé tunely, bridge, filtry, firewall, cron(!) atd. Je to vlastně malinký linuxový počítač s minimální spotřebou, 16 MB RAM, 4 MB flash, rychlým procesorem (182 MHz), 5 ethernet porty a WiFi... to by člověk nevěřil, co krabička za 800 korun dokáže. Není to paráda?

ASUS WL500gP: zavřete notebooky, odcházím...

Nový (rok a půl starý) ASUS WL500gP WiFi AP fungoval přesně 10 dní. Včera odpoledne jeho WiFi signál zase (stejně jako v předchozích případech) prostě zmizel. Běžné zaříkávání nepomohlo, musel jsem klesnout až k výměně firmware a ještě ho nechat odstát přes noc... Tohle není normální.

Zvažuji ještě zkusit nainstalovat DD-WRT, ale psychicky se už připravuji na další reklamaci a pak výběr nového, nějakého méně dokonalého WiFi AP. Kdepak je asi zakopaný pes, že mi to WiFi tak končí?

Reklamace ala ASUS

Můj starý dobrý (vyrobený v dubnu 2007) nový (koupený v září t.r.) WiFi router ASUS WL-500g Premium byl opravdu z vadné série, jak mi potvrdila technická podpora ASUSu v Ostravě. Tak tedy dobrá, nezbylo než ho poslat na opravu. Jal jsem se tedy čekat. Byl jsem dlouho offline. Netrpělivý. 3 týdny a pořád nic? Už jsem nedočkavý!

Dnes konečně přijel router z reklamace zpět. Úplně nový! Originálně zabalený. Krásný. Ale vyrobený v květnu 2007 - tedy taky z vadné série...

Někdy je opravdu těžké zachovat chladnou hlavu a dekorum.

Když wifi zkazí svátek

Začátkem září jsem si koupil wifi router ASUS WL-500g Premium, na kterém mě fascinovala především možnost nahradit originální linuxový firmware za plně otevřený a rozšiřitelný systém. Nacpal jsem tam Olegův nejnovější kousek a tak získal úsporný, trvale běžící SSH server, přes který můžu pomocí WoL probouzet ostatní domácí počítače a tak se odkudkoliv ze světa vždycky dostat ke svým datům nebo MythTV nahrávkám. Zároveň mám wifi signálem pokrytý dům a okolí, což přináší zcela revoluční možnosti (např. můžu čistit bazén od napadaného listí, žížal a myší/rejsků a zároveň si číst novinky na webu :-)



Vše fungovalo výborně asi týden či dva, než nastal nějaký hezký víkend, kdy se z ničeho nic wifi signál vytratil. Prostě nebyl, ačkoliv krabička trvala na tom, že radio je zapnuté a že vysílá. Vrátil jsem původní firmware, signál se nevrátil. Vlastně chvílemi se jakoby objevoval, ale zase hned mizel. Půl soboty a celou neděli jsem to ladil a nic nevyladil. Když jsem se rozhodl tu věc reklamovat, wifi se opět rozeběhlo a vše jelo. Vrátil jsem Olegův firmware, stále vše jelo. Postupně jsem na celou anabázi zapomněl.

A včera večer, v předvečer 90. výročí založení samostatné ČSR, ASUS opět udeřil. Opět bez varování zmizel signál, opět jsem vrátil původní firmware, překonfigurovával stále WEP/WPA/WPA2 atd., ale stále nic. Vlastně polonic - chvílemi se prostě signál objevil a pak zas zmizel. Jaké to je být pět minut online, rozepsat zprávu a pak ztratit spojení? Grrr... Pročetl jsem tisíce zpráv na různých fórech a dočetl se až k tomu, že moje krabička (koupená v září 2008) je zřejmě (dle sériového čísla 74IEACxxxx) vyrobená už v dubnu 2007, kdy se ale chybou ve výrobě montoval na vnitřní miniPCI kartu omylem 1000x větší odpor R17, což v podstatě vypíná zesilovač wifi signálu. To sice může rozhodovat na sto metrů, ale já tu sedím od vysílače jen 1 metr, a ten signál je buďto 100%, nebo prostě zmizí a není vůbec...

Budiž, možná že je to opravdu vadný kousek z rok a půl staré série (kde se celou tu dobu toulal?), ale proč ten signál mizí a zase se náhodně objevuje? O tom jsem se nikde nic nedočetl. Vypadá to skoro jako problém s přehříváním něčeho uvnitř, co musí vždycky trochu zchládnout, aby to zas chvíli mohlo vysílat... Každopádně mi to zcela zkazilo svátek. Nemám rád, když technika nepracuje jak má a navíc se chová, jako by v ní byli skřítci...

ohloh

Hledal jsem jak udělat nějakou drobnost v PHP a automaticky jsem zašel na web PHP triky, protože vím, že tam jeho autor Jakub Vrána má fajn vychytávky. Poprvé jsem se ale ocitl na titulní stránce, která nabízela zajímavý rozcestník. Zabloudil jsem nejdřív do sekce nabízející výstižně zkrácené popisy děje filmů (Kazifilm) - líbí se mi důvod, a chápu jej, taky mám tak "pružnou" paměť :-) Pak jsem, s pocitem, že souzním s autorem, zavítal do osobních stránek, kde mě ihned zaujal jeho příspěvek o komunitních sítích. I tady jsem byl s autorem naladěn na stejné vlně, tak jsem nezaváhal a Ohloh navštívil.

Ohloh je to opravdu dobře vymyšlený a udělaný. Hned jsem se tam zapsal a připsal si i open source projekty, ve kterých figuruji. Zajímavé je jejich různorodé hodnocení - např. přepočet strávených člověko-hodin na peníze - to by pak např. můj oblíbený ARAnyM stál skoro 2 milióny US dolarů, kdyby měl být vyvinut/byl vyvíjen komerčně.

Přemýšlím taky o tom vést si tam žurnál o programovacích aktivitách. Dá se tam totiž publikovat pouhým posláním Jabber zprávy, což bych byl ochoten a schopen dělat poměrně často, minimálně kdykoliv se chystám zvelebit některý z těch "mých" open source projektů :-)

WiFi out, ADSL in

Právě jsem přešel s domácím připojením na ADSL. Po více než 6 letech relativní spokojenosti s místním WiFi poskytovatelem internetu se začaly objevovat výpadky v tu nejnevhodnější dobu, takže už na internet nebylo spolehnutí a bez spolehlivého připojení k internetu to dnes, dámy a pánové, zkrátka nejde :-)

Začínal jsem s WiFi v dubnu 2002 na 64 kbps s extra krutým FUPem (250 MB/měsíc a 8 Kč za nadlimitní MB), ovšem proti vytáčenému spojení o rychlosti někdy až 33,6 kbps a účtovanému po načatých minutách to byl pořád velký krok k rychlosti a svobodě. Stálo to tehdy 900 Kč měsíčně a platil jsem je rád. Dnes jsem za 600 Kč/měsíc měl 3 Mbps / 512 kbps s 15 GB FUPem (naštěstí už se neplatí za nadlimitní data, jen by se to zpomalilo na nepoužitelných 128 kbps). Rychlost dobrá, ping do NIXu za 17 ms, ale ta spolehlivost...

No a teď svištím na Volného ADSL na LLU, 4 Mbps/384 kbps za 700 Kč/měsíc a i když jsem 5 km od ústředny, tak první měření ukazují přes 3700 kbps download, což je až nečekaný úspěch. Upload sice drhne na nějakých 320+ kbps, ale když si platím 384 kbps, tak to asi o moc lepší být nemohlo. Uvidíme v září, kdy si požádám o upgrade na 8 Mbps/512 kbps...



Ještě doma musím trochu předělat celou síť - původně byl totiž WiFi modem nastavený jako bridge a funkci routeru s NAT a DHCP serverem plnil až Linksys (Sipura) VoIP strojek. Ale ten ADSL modem mi přišel mnohem chytřejší, takže jsem se ho zkusil pasovat do role routeru s NATem, a Linksyse jsem pokusně přepl do bridge módu. Tím jsem se ovšem nádherně odřízl od přístupu k němu, protože v bridge módu se dá dovnitř dostat jen přes WAN rozhraní, kde jsem měl původně samozřejmě webové rozhraní zakázané. Naštěstí ten VoIP zázrak oplývá ještě i konfigurací přes normální telefonní sluchátko (tónovou volbou a hlasem), takže jsem ho nakonec přenastavil a trochu ovládl. Teď ale nemám pod kontrolou DHCP server (Linksys uměl přidělovat IP adresy dle MAC, to ten WELL PTI-8111 modem neumí), takže to ještě musím nějak lépe promyslet...

OpenUPSmart opraven

Tak jsem věnoval dva celé večery opravám programu OpenUPSmart, který umí řídit mou domácí Blackout Buster UPS. Používal jsem ho v Debianu už několik let, a vždycky mě štvalo, že každých pár sekund vysype na terminál nějaké ladicí hlášky o napětí a kmitočtu v elektrické síti, takže práce v konzoli byla prakticky nemožná. Ovšem nikdy jsem se nedonutil ho opravit - až teď, s přechodem na Ubuntu, jsem si řekl, že by bylo dobré to konečně vyřešit.

Když jsem se v programu po chvíli rozkoukal, nevěřil jsem vlastním očím, kolik chybiček tam jeho autor nasekal. Na to, že je to verze 1.0 a že na to už 4 roky nesáhl, je to opravdu žalostné. Připomnělo mi to, že člověk se musí pořád snažit psát co nejlepší kód, aby si v Open Source světě neutrhl ostudu. Tím ale autora nechci nijak hanit - pořád je lepší vydat program pod licencí GNU GPL, která umožní dalším lidem program opravit a vylepšit, než vydat jen binární balíček, anebo dokonce nedat nikomu nic a nechat si všechno jen sám pro sebe.

Nakonec mi ta oprava zabrala víc času, než jsem čekal, protože jsem nacházel další a další drobnosti. Chtělo by to celé přepsat, ale chybí síla a čas, tak to nechám jak to je - teď to funguje OK a to je dobře. Změny jsem poslal autorovi, ale nečekám, že jakkoliv zareaguje (je to už přecejen dlouho a nejspíš už sám má úplně jinou UPS), takže jsem je poslal jako patch i k tomu projektu na SourceForge.net. A zájemcům můžu poslat binární balíček pro Debian/Ubuntu.

Virtuální benchmark

Pracovní povinnosti mě přivedly po 10 letech zpět k operačnímu systému Maličkájemná Okna, ale protože se Pravého systému nevzdám a na výpověď jsem to neviděl, rozhodl jsem se pro virtuální řešení ve stylu vlk se nažral a kozy zůstaly celé, nebo-li pro provoz Windows ve virtuálním stroji běžícím v Ubuntu.

Po katastrofických zimních zkušenostech s VMware Server 2.0beta (systém uvnitř se zpomaloval, až se nakonec zastavil) jsem šáhl rovnou po VirtualBoxu. Po celodenním záplatování XP jsem nakonec zjistil, že VirtualBox nenechá virtualizovaný systém využít celou sílu dual core Athlonu - pustí mu jen jedno jádro, což se mi zdálo málo, protože potřebuji maximální výkon kompilace i běhu aplikace a databáze. Tak jsem se sebezapřením šáhl po VMware Playeru a po marném pokusu zkonvertovat existující disk image z VirtualBoxu (modrá smrt okamžitě při bootu) jsem začal celou XP instalaci od píky. A jak jsem tak instaloval a instaloval, tak se mi to pořád zdálo strašně líné, grafika jak hlemýžď, překreslování všeho nesmírně pomalé. Abych vyloučil subjektivní pocity, vygoogloval jsem pěkný test 2D grafiky v Performance Test 6.1. A zde jsou výsledky:

Test Name	VMware Player 2.0.4	VirtualBox 1.6.2
CPU - Integer Math	105.0	73.7
CPU - Floating Point Math	639.2	356.3
CPU - Find Prime Numbers	195.9	177.9
CPU - SSE/3DNow!	2290.4	1728.9
CPU - Compression	3106.4	2191.7
CPU - Encryption	22.3	17.3
CPU - Image Rotation	497.2	334.7
CPU - String Sorting	1673.1	1361.4
Graphics 2D - Lines	5.9	6.0
Graphics 2D - Rectangles	32.3	10.4
Graphics 2D - Shapes	1.7	5.4
Graphics 2D - Fonts and Text	19.1	58.1
Graphics 2D - GUI	37.8	221.4
Memory - Allocate Small Block	1087.4	1882.6
Memory - Read Cached	659.2	1300.1
Memory - Read Uncached	522.8	1152.5
Memory - Write	571.1	1179.0
Memory - Large RAM	46.8	228.9
Disk - Sequential Read	43.4	150.4
Disk - Sequential Write	14.1	78.3
Disk - Random Seek + RW	6.1	147.1
CPU Mark	698.2	516.9
2D Graphics Mark	66.9	131.5
Memory Mark	213.5	424.6
Disk Mark	230.0	1359.1
PassMark Rating	282.3	506.2

V podstatě se dá říct, že zatímco VMware pro výpočty vskutku používá obě jádra a hrubý početní výkon je tak opravdu vyšší (700 vs 500 bodů v CPU Mark), tak grafiku má výrazně pomalejší (pěkně vidět v GUI - 38 vs 221 bodů). Pořád to bylo celkem fifty-fifty - oželel bych překreslování oken, pokud by to kompilovalo o polovinu rychleji - ale pak jsem uviděl testy paměti a disku a bylo rozhodnuto - vrátil jsem se zpět k jednojádrovému VirtualBoxu.

Vůbec nerozumím tomu, proč u paravirtualizace je tak výrazný propad výkonu v přístupu do paměti u VMware Playeru (2x pomalejší!), když oba nástroje to musí dělat v podstatě stejně. O rychlosti disku ani nemluvím... Teprve příští dny ale rozhodnou, jak se to vlastně bude chovat v reálném nasazení (Visual Studio, ASP.Net, IBM DB2, ...)