Moderní web a potíže se staršími a méně výkonnými počítači

Nedávno jsem zaregistroval kritiku Linuxu, že je pomalý na 15 let starém Pentiu s 128M RAM. Dotyčný tvrdil, že po Linuxu chtěl „jen“ přehrát video z YouTube. V tu chvíli jsem si vzpomněl na svoje nedávné problémy s jedním ne tak starým jednojádrovým Atomem, kde je dost RAM (8G), akorát YouTube tam běží žalostně pomalu.

Zjišťuji, že u starších počítačů jsou největším problémem právě nároky moderních webových aplikací běžících v moderních webových prohlížečích. Místní aplikace pro kancelářskou práci obvykle jedou a skoro veškeré základní programové vybavení se dá rozumně používat. Kromě moderního webu.

Když se podívám na úvodní stránku YouTube, provede můj Firefox celkem 124 (!) HTTP požadavků a přenese cca 7.5MB dat. Asi je v tom i to krátké reklamní video, které se samozřejmě automaticky přehrává. Součástí je celkem 21 externích JavaScriptů, které dají dohromady 2.6 MB kódu (!). JavaScript je ve své podstatě programový kód, který vykonává JavaScriptový engine prohlížeče. Je to interpretovaný kód, tudíž je to samo o sobě pomalé, a množství tohoto kódu používaného na webových stránkách stále stoupá.

Videa, která se dnes přehrávají na YouTube, používají kodeky jako H.264 nebo VP8, které jsou samozřejmě velmi náročné na CPU, pokud nemáte grafiku, na které se to dá dekódovat. Staré systémy se u přehrávání moderního videa prostě nechytnou.

Chápu, že dotyčný vnímá YouTube za něco zcela normálního a běžného, ale když si uvědomíte souvislosti a dojde vám, kolik funkčnosti moderní webové stránky svěřují vašim počítačům, vašim procesorům, vašim grafickým kartám a potažmo vašim peněženkám (v podobě účtů za elektřinu), pak se nemůžete divit, že na velmi starém počítači s mizivým výkonem na dnešní poměry prostě s moderními/náročnými webovými stránkami nemáte sebemenší šanci a Linux s tím nic neudělá, ani kdyby se postavil na hlavu a odstrkoval ušima.

Web se nám prostě za ty roky k nepoznání změnil a je to dle mého soudu právě moderní web, který použitelnost mnoha starších počítačů spolehlivě likviduje.

Btw, pokud chcete prohlížet web na starších počítačích a stačí vám text, můžete zkusit řádkové prohlížeče jako Lynx, Links, W3M, apod., a v případě grafických aplikací můžete zkusit třeba Dillo. Samozřejmě YouTube vám zůstane zapovězený, ale alespoň něco málo zvládnete.

Prohlížení webu přes SSH SOCK5 proxy

OpenSSH toho umí poměrně hodně a není proto divu, že se o něm píší i celé knihy. Jednou jeho zajímavou vlastností je možnost vytvořit SOCKS5 proxy, která bude veškerou komunikaci směrovat přes SSH. Máte-li tedy SSH účet na nějakém serveru, kde to administrátor nezakázal, můžete surfovat „přes“ něj. Příkaz pro vytvoření SOCKS5 proxy vypadá takto:

ssh -D 8888 -Nf uzivatel@example.com

Parametr volby -D určuje místní port, kde bude sídlit SOCKS5 proxy. Tento port na localhostu je pak samozřejmě třeba nastavit v prohlížeči.

Vlastosti a výhody tohoto nástroje jsou:

  1. komunikace je šifrována mezi vámi a SSH serverem, váš ISP tedy nebude mít šanci sledovat obsah vaší komunikace
  2. SOCKS5 proxy umí tunelovat nejenom vlastní komunikaci, ale i DNS dotazy (doporučuji se ujistit Wiresharkem, ne všechen software to nutně umí), tudíž, pokud váš prohlížeč neprosakuje, váš ISP by neměl mít šanci zjistit s jakými weby komunikujete sledováním DNS provozu
  3. komunikace samozřejmě není šifrována mezi SSH serverem a cílovým serverem, tudíž správce tohoto serveru a/nebo váš „serverový“ ISP uvidí jak komunikaci, tak DNS dotazy

Mezi důvody, proč tento nástroj použít, může patřit:

  • jste někde připojeni přes nešifrovanou nebo neznámou WiFi
  • nedůvěřujete svému ISP
  • jste připojeni přes cenzurujícího ISP
  • chcete obejít omezení přístupu na nějaký web (některé weby jsou dostupné např. pouze z USA nebo jiné země)
  • chcete extra-bezpečně přistupovat k webu umístěném přímo na daném serveru s SSH
  • atd.

Přirozeně, tento nástroj je možné použít i s jiným softwarem než nutně s prohlížečem, stačí podpora SOCKS5.

Jinke Hanlin a vleklá chyba s češtinou v epub

Zklamali mne čeští distributoři těchto čteček e-knih, jelikož o docela podstatném problému, jakým je nezobrazování korektních českých znaků v případě knih ve formátu epub, vědí řádově roky, a doteď ho nebyli schopni vyřešit. Problém spočívá v tom, že software určený k prohlížení epub souborů používá font bez některých českých znaků s diakritikou. Paradoxně, byť čtečky jako takové umožňují změnu fontu, v případě formátu epub to nejde (ten software to neumožňuje).

Nejnovější anglický firmware již umí u epub měnit font, česká varianta firmwaru ale není dostupná (byť byl čas od dubna 2011, kdy firmware vyšel) a anglický firmware nemá (překvapivě) podporu pro český jazyk.

Nouzovým řešením je upravit e-knihu, aby používala jiné fonty. Lze buď postavit fonty mimo epub a z něj se odkazovat na pevné umístění na kartě, nebo fonty „zadrátovat“ do knihy (pak je kniha v této podobě pěkně přenositelná). Obojí představuje nutnost upravit knihu, což není úplně triviální.

Za tímto účelem jsem pro vlastní potřebu vytvořil shellový skript, který fonty natvrdo zadrátuje do e-knihy. Kód není nic moc a nezaručuji, že to bude fungovat u všech e-knih. Stejně nezaručuji, že skript neudělá nějakou neplechu. Pokud jste ochotni se skriptem pracovat na vlastní riziko a s vědomím, že se jedná o nedostatečně otestovaný skript, kde mohou číhat příšerné chyby s možnými fatálními důsledky, můžete si jej stáhnout (5Kb) – v opačném případě nic nestahujte a alespoň pište rozhořčené e-maily českému distributorovi. Skript se používá se takto (vyžaduje to Bash, sed, zip a unzip a další běžné unixové nástroje):

./hanlinize mybook1.epub mybook2.epub

Je to špinavé řešení, ale třeba OpenMagazín to upraví korektně. Místního distributora těchto čteček bych rád pokáral za jeho netečnost. „Pěkné“ je také to, že aktuální český firmware nelze odnikud stáhnout (oficiální odkazy jsou mrtvé), a jelikož firmware nejde před změnou zazálohovat, je třeba případné experimenty s jiným firmwarem zvážit (přijdete o nejnovější verzi českého firmwaru, který tam už nedostanete, dokud se distributor nezmátoří a neupraví odkazy na svém webu). To také považuji za nešťastné. Přitom to jsou schopné a levné čtečky, navíc na Linuxu založené (i když to jsou asi všechny).

Kdybyste potřebovali výsledný epub upravit nebo zkontrolovat, můžete využít vynikající epub editor Sigil.

Zdroje a další informace:

Drupale, Drupale, ty jeden lumpe

Právě se zabývám nasazením Drupalu jako CMS v jednom svém projektu. Jelikož je již k dispozici stabilní vydání z nové řady 7.0, rozhodl jsem se použít právě to (nechtělo se mi použít verzi 6 a po čase řešit upgrade na sedmičkovou řadu). Samozřejmě nelze očekávat, že nová řada bude zcela bez chyb, nicméně je-li k dispozici stabilní vydání, domníval jsem se, že alespoň ty nejvíce do očí bijící chyby a nepříjemnosti budou odstraněny.

Pro realizaci řady pravidelných interních činnosti je v Drupalu použit cron. Jednou ze stěžejních funkcí, alespoň z hlediska bezpečnosti, je ověření stavu dostupných aktualizací, aby správce tušil, kdy vyšla bezpečnostní aktualizace, a kdy má CMS aktualizovat. Stav aktualizací se má zkontrolovat při běhu cronu. Bohužel se tak ale u sedmičkové řady neděje. Drupal vám sice říká, že máte spustit cron ke zjištění dostupných aktualizací, ale spuštění cronu stav nezkontroluje a hláška zůstává. Nezbývá tedy než aktualizace kontrolovat ručně.

Chyba byla nahlášena v prosinci roku 2009, Drupal 7.0 (stable) vyšel 5. ledna 2011, avšak chyba nebyla dosud (březen 2011) opravena. Samozřejmě si nesmírně vážím vývojářů Drupalu, Drupal samotný považuji za vynikající CMS a rozhodně nemám v úmyslu tento projekt nijak shazovat či kritizovat, jen se trošku podivuji nad tím, že takový problém nechali při vypuštění dlouho očekávané nové verze nevyřešený a že ani 3 měsíce po jejím vypuštění není k dispozici alespoň patch.

Význam svobody softwaru

V jedné dávné diskusi jsem byl dotázán, k čemu jako uživatel softwaru potřebuji svobodu. Dotyčný přišel s materiální analogií, tedy s příkladem konkrétního, fyzického nástroje, který si koupím, ale nedostanu k němu dokumentaci, jak byl sestaven. Daný nástroj používám, pokud mi vyhovuje, a pokud ne, koupím si jiný. Proč mi tato analogie přijde zcestná? A proč si myslím, že svoboda softwaru je klíčová?

Celý příspěvek

Přátelé Open Source

Dnes jsem uzřel zprávičku o IBM, kterak hrozí patentovým sporem firmě, která vyvíjí open source software. Součástí patentového sporu jsou i dva patenty, které IBM přislíbilo open source vývojářům. V souvislosti s tím mne napadlo následující:

Open source nemá přátele. Pouze své tvůrce, uživatele, zneuživatele a nepřátele.

Pravdou je, že open source má kromě tvůrců a uživatelů své nepřátele – obvykle konkurenty z prostředí proprietárního softwaru. Jako zneuživatele bych viděl někoho, kdo začne na nějakém open source projektu rýžovat, aniž by cokoliv vrátil zpět původním lidem, z jejichž práce těží. Ale to je sporné – pokud dotyční daný software vydali pod jistými licenčními podmínkami, pak mohli s podobným scénářem počítat (dovoluje-li to licence), a tudíž se nejedná o zneužití.

Kdo je ale přítelem open source? Nejsem si jistý, kdo by tak mohl být označen (uživatel je uživatel, vývojář je vývojář…). Vím ale to, že přítelem open source rozhodně není entita, jejímž primárním cílem je dosažení zisku (tedy jakákoliv komerční společnost). Ta totiž bude stát za Open Source jen tak dlouho, dokud se jí to vyplatí, a jakmile se situace změní, bez jakýchkoliv rozpaků vytáhne nůž a vrazí mu ho do zad. Firmy podle mého nejsou a nemohou být přáteli Open Source. Zejména pak Ubersoft.

Publikování na WordPress (nejen) pomocí (G)Vimu

Mám rád Vim. Mám moc rád Vim. Používám ho k editaci textu při každé možné příležitosti. Problémem je, že redakční systémy typu WordPress se obvykle ovládají přes webové rozhraní, a přes toto rozhraní se přidává i obsah. Naštěstí WordPress umožňuje i přístup přes xmlrpc rozhraní, což dává vývojářům možnost vytvořit pro ovládání WordPressu alternativní rozhraní.

Toto využívá celá řada „bloggerů“ coby aplikací pro desktop, ale i pro příkazovou řádku. Jednou z aplikací pro příkazovou řádku je blogpost, napsaný Stuartem Rackhamem v Pythonu. Umí publikovat jako článek nebo stránku soubor formátovaný buď v HTML nebo v AsciiDoc. Netestoval jsem, ale na první pohled vypadá zajímavě.

Nicméně, zpět k hlavnímu tématu – publikovat na WordPress lze i z (G)Vimu, a to pomocí několika pluginů. Já jsem pro své potřeby zvolil aktivně vyvíjený Blogit, u kterého mne jeho vývojář velmi příjemně překvapil, když mnou nahlášený bug úspěšně vyřešil v řádu hodin (nyní už není problém s názvy kategorií v Unicode).

Plugin Blogit přináší do Vimu několik příkazů:

:Blogit ls [blog]          list all posts
:Blogit new [blog]         create a new post
:Blogit this [blog]        make this a blog post
:Blogit edit {id} [blog]   edit a post
:Blogit page {id} [blog]   edit a page
:Blogit commit             commit current post or comments
:Blogit push               publish post
:Blogit unpush             unpublish post
:Blogit rm {id}            remove a post
:Blogit tags               update and list tags and categories
:Blogit preview            preview current post locally

S pomocí nich je velmi snadné vytvořit nový příspěvek nebo editovat stávající, a to včetně práce se stránkami (pages). Blogit nabízí také doplňování tagů a kategorií prostřednictvím C-X C-U.

Co více napsat? Pokud používáte Vim a máte někde blog nebo stránky využívající Wodpress, určitě Blogit vyzkoušejte. Pokud používáte jiný CMS, a rádi byste editovali texty příspěvků ve Vimu, můžete použít plugin do Firefoxu s názvem Vimperator, který vám z Firefoxu udělá tak trochu Vim (z hlediska ovládání) a umožní vám upravovat formulářová pole GVimem prostřednictvím C-I.

No a pokud máte rádi Emacs, určitě znáte Conkeror.

IM, AOL, ICQ, Jabber, protokol, klient, atd.

Abych pravdu řekl, samotnému mi činilo problémy orientovat se ve všech těchto pojmech. Pokusím se tedy o objasnění těchto pojmů, co možná nejjednodušeji.

IM (Instant Messaging) je způsob komunikace pomocí „okamžitých zpráv“. K tomu, abyste si mohli s někým tímto způsobem „psát“, potřebujete poskytovatele takové služby. To je obvykle subjekt, který vlastní servery, ke kterým se připojujete a přes které IM komunikaci realizujete. Přirozeně tak nečiníte ručně, nýbrž pomocí klienta, tedy programu, který s příslušnými servery komunikuje, pomocí určitého způsobu dorozumívání, který se označuje jako protokol.

ICQ je označení pro klienta, tedy program, který komunikuje se servery poskytovatele (AOL), prostřednictvím protokolu OSCAR. ICQ je oficiální klient pro tuto službu. Existují i další klienti, např. Miranda, QIP, Licq, SIM, Gaim, atd. Podmínky služby však použití těchto „neoficiálních“ klientů zakazují. Mimo jiné.

Aby to nebylo tak jednoduché, klienti mohou podporovat více protokolů, a umožňovat tak uživateli být přihlášen např. na ICQ i Jabber současně. Takové klienty označujeme jako multiprotokolové.

IM služby můžeme dělit do dvou kategorií – centralizované (uzavřené) a decentralizované (otevřené). Mezi centralizované IM služby patří ICQ, MSN, Gadu-Gadu a celá řada dalších. Tyto služby jsou zpravidla vázány na specifického klienta a podmínky uživatelům zakazují používání čehokoliv jiného. Stejně tak, poskytovatelé těchto služeb zpravidla znemožňují uživatelům kontaktovat uživatele jiných IM služeb.

Mezi decentralizované IM služby patří Jabber. Jabber je otevřená technologie, kterou může adoptovat kdokoliv (kupříkladu, i já mám svůj vlastní Jabber server), podobně jako třeba e-mail. Není závislá na jediném subjektu, poskytovatelem se může stát kdokoliv. Z toho vyplývá, že v případě Jabberu máte možnost vybrat si takového poskytovatele (resp. takový server), který vám vyhovuje, ovšem to vás nijak neomezí v možnosti kontaktovat uživatele jiných Jabber serverů. Uživatelé Jabberu mohou dokonce pomocí transportů kontaktovat uživatele jiných sítí (ICQ, MSN, apod.). Klientů pro Jabber existuje celá řada a uživatelé nejsou v jejich volbě nijak omezováni.