Planeta.OpenAlt.org

V minulém článku jsem se dotkl výkonu ZFS na FreeBSD a to v úloze mazání většího množství (malých) souborů. Ve skutečnosti to ale není ten hlavní problém, který mě na ZFS trápí. Jak již bylo napsáno, mazání pracovního adresáře lze hravě vyřešit tak, že jej budeme vytvářet jako samostatný dataset, který na konci práce smažeme celý.

Hlavní problém, který aktuálně řeším (a TLDR: ani v tomto článku jej nevyřešíme) je pomalý průchod adresářovým stromem. Viz ukázka:

$ time find . | wc -l
   344666
 real    4m44.282s
 user    0m0.372s
 sys     0m2.861s

Což je jen dost těžko akceptovatelné a navíc za situace, kdy OS z nějakého důvodu tato metadata po chvíli (do 20 minut, přesněji jsem to nehlídal), zapomene a při dalším find opět čekáte 4 minuty. Což je zajímavé samo o sobě, lze asi akceptovat, že se z cache musí odstranit část metadat, ale jistě ne pro celý tento adresářový strom.

Tohle bohužel nemá tak přímočaré řešení jako problém s mazání, které lze vyřešit vlastním dočasným datasetem. V tomto případě, kdy je nutné občas prohledat (měnící se) adresářový strom pro nějaké jméno by se jistě našlo řešení v podobě indexu jmen, ale to by ovšem znamenalo, že všechny nástroje pracující na tomto stromu by muselo tento index měnit. Potom ovšem padá jakýkoliv důvod přímo používat a lze mít data v DB.

Á propós:

add=> \timing
 Timing is on.

add=> select count(*) from files;

  count
 106407926
 (1 row)

Time: 36456.988 ms (00:36.457)

Tabulka files obsahuje metadata k těm 106mil. souborům a dotaz, který vede na full table scan, je prakticky stejný jako ten find | wc -l. DB to zvládá rychlostí téměř 3 miliony záznamů za sekundu. Běží na stejném zpoolu jako výše testovaný zfs dataset. Ten to zvládá rychlostí 1213 souborů / s. Tedy 2.5 tisíckrát pomaleji.

Zarážející je, že z těch 4m44s jen cca 3s jsou v systému. Zdá se, že OS čeká na něco. Ale na co? Na disky? Nezdá se. Podle zpool iostat -v se disky nudí. Celý zpool má během „operace find“ 183 IOPS, což je 3x méně, než by mohl mít, pokud by disky byly zatížené na 100%:

Disky, zdá se, běží na 30% max svých možností. Podívejme se na iostat -x:

Ten to jen potvrzuje. Disky zpoolu jsou vytížené kolem 20%, maximálně 30%.

Jak jsem prozradil už na počátku, nevím, čím je to dané. Disky jsou zdravé a v jiných operacích podávají očekávaný výkon. Nemám nic pořádného v ruce, jen několik nepotvrzených hypotéz.

Jednou z těchto hypotéz, která mě napadla už u minulého článku, zda je výkon zpoolu skutečně takový, jak si představuji. Jedna věc je počítat hrubý výkon šesti disků a jiná věc je potom skutečný výkon v reálném provozu. Takže jsem otestoval sekvenční čtení (cat soubor > /dev/null) a výsledek kolem 400-500MB/s je očekávaný a v pořádku. Tady tedy problém nebyl. Ovšem opakované čtení stejného souboru dávalo stejné výsledky. ZFS jej vůbec necachoval ani po dvaceti čteních. Ano, ARC pracuje složitěji než klasické cache, ale že by ji ani dvacet čtení nepřesvědčilo, je divné.

Takže jsem stejný soubor přesunul na UFS2 a otestoval tam. Šel okamžitě to cache. Potom zpět na ZFS. A dvě čtení stačí na přesun do ARC. Zdá se tedy, že něco v historii zpoolu, zfs, datasetu nebo způsob vytvoření toho konkrétního souboru zabránilo ARC v jeho cachování. Nevím. Jen nepotvrzené hypotézy.

Jen na okraj. Porovnání rychlosti čtení z FreeBSD cache a z ZFS ARC: Pokud už se soubor dostane do ARC, rychlost čtení na daném stroji (fx8350) je 2.15GiB/s. Rychlost čtení z FreeBSD cache (pro UFS2): 3.75GiB/s. ARC je složitější, zatímco FreeBSD cache je nativní a roky optimalizovaná. Jenže rychlost čtení 2GiB/s se dá dneska dosáhnout i z levných NVMe disků. Jasně, je to porovnání opět mimo mísu, protože tento stroj (2013 FX8350) podporou NVMe rozhodně netrpí, na druhou stranu je taková rychlost „RAM“ cache k zamyšlení. Zejména, když nativní cache je skoro 2x rychlejší.

Pár slov na závěr. Už při psaní minulého článku během testů odstraňování souborů jsem si uvědomil jednu věc. Zbytek systému bez problému běží dál jako by se nechumelilo. Vlastně tomu odpovídá celá moje zkušenost s FreeBSD od samého počátku. Ten systém prostě běží vlastním tempem a prakticky žádná operace jej nezablokuje (ještě se mi to cíleně nepodařilo). To, že se někde 40 minut maže adresářový strom vlastně nic neznamená, jaily běží dál, zfs send si jede de facto nezměněnou rychlostí, data přes sambu a nfs jsou dostupná. Na linuxu se mi několikrát podařilo systém zablokovat přes náročné IO, mnozí uživatelé mají špatnou zkušenost s kopírováním na USB flash disky (příčinou je příliš velká dirty cache a příliš pomalý usb disk), apod. Z tohoto ohledu je FreeBSD mnohem plynulejší. Možná je to způsobeno nedokonalostí IO scheduleru, který (další nepotvrzená hypotéza) raději vkládá prázdné cykly než aby zabil IO pro zbytek systému, možná je v tom něco jiného. I tento ZFS běží perfektně a funguje skvěle pro reálné programy (db během toho full table scanu četla 350MB/s), odstraňování se dá obejít smazáním celého datasetu a takto velký adresářový strom má mít stejně index (a upřímně, v mém uvažování stejně patří do DB).

V Linuxu odjakživa používám hodně ploch, obvykle 12. Jsem zvyklý mít na každé z nich konkrétní software, takže nemusím přemýšlet, co kde mám, prostě to tam je.

Na první ploše mám poštovní program, obvykle Thunderbird. Na druhé Firefox, na třetí poznámky Zim (dříve tu býval Jabber klient, ale to už je dávno), na čtvrté Chromium, na páté správce souborů, na šesté editor kódu, na sedmé prohlížeč nebo editor obrázků, na osmé kancelářský balík, na deváté Telegram, na desáté volno, na jedenácté terminál, na dvanácté FTP klient FileZillu. Přehrávač hudby se zobrazuje podle potřeba kdekoliv, protože ho hned zase skrývám.

Plochy ovládám klávesovými zkratkami:

• Ctrl-Fx pro přepnutí na plochu,
• Alt-Fx pro odeslání programu na plochu.

Zjistil jsem, že Mutter, správce oken v GNOME, umožní nastavit v běžném konfiguračním okně klávesové zkratky pouze pro čtyři plochy. To je málo. Naštěstí jsem se nenechal odradit a řešení jsem našel (nedávalo mi to smysl a omezení chápu jen s ohledem na laické uživatele, kteří princip ploch sotva používají).

Spusťte editor dconf, najděte strom /org/gnome/desktop/wm/keybindings/ a zde v seznamu move-to-workspace-xx a switch-to-workspace-xx. Klávesová zkratka se zadává ve formátu ​['<Alt>F11']. Úprava funguje ihned.

Rádo se stalo.

Úprava klávesovek pomocí dconf

Aktualizace článku

• 12.4. Informace o FIDO a podpoře dalších browserů založených na Chromiu

Google už nabízí vlastní bezpečnostní klíč Titan. Stojí $50, musíte ho párovat (v případě Bluetooth verze) nebo připojovat do USB (a do USB-C navíc přes redukci) a je to prostě další věc, kterou musíte nosit. Jsem si celkem jist, že něco z toho od používání odradí naprostou většinu uživatelů. Ani výrobce YubiKey, podobných ověřovacích čudlů, nebyl z Titanu příliš nadšený.

Bezpečnostní klíče Google Titan (zdroj)

Google pro 2FA podporuje i tzv. výzvy (Google Prompt): po zadání jména a hesla vás telefon (Android nebo iOS s patřičnou aplikací) připojený k Internetu vyzve, abyste potvrdili, že jste to opravdu vy. Tohle je skvělé, jen potřebujete připojení k Internetu v telefonu (a dá se to použít jen pro Google).

Bezpečnostní klíč vestavěný v Androidu funguje podobně, ale nepotřebuje ani ten Internet. Google zatím neprozradil jak je to vyřešeno technicky, nicméně když v browseru vypnu podporu Bluetooth klíčů pro Web Authentication API, tak to stále funguje. Že by to používalo spíš U2F API (které je založené na FIDO U2F API)? Vypadá to tak, FIDO je zmíněno i na stránce s popisem bezpečnostních klíčů a Android 7+ je „FIDO2 Certified“ od února.

Snad je bezpečnostní klíč v mobilu postavený na standardech a takové ověřování bude brzy dostupné i pro jiné služby, systémy a aplikace. Moc se mi líbí, že se na tomhle poli něco děje a nezůstáváme jen u přepisování číslíček, která se každých 30 sekund mění. Čím víc to bude pro lidi jednoduchý, tím víc to budou používat a tím méně je nějaká uniklá hesla ohrozí. Bezpečnostní klíče jsou mnohem bezpečnější než SMS i opisování kódů, nemůžete je totiž zadat do jiné stránky – jsou odolné proti phishingu.

Takhle se to používá

Pokud si chcete používání bezpečnostního klíče vestavěného do Androidu nastavit, tak se můžete podívat do nápovědy Googlu nebo na moje screenshoty tu.

V nastavení dvoufázového ověření si můžete zvolit, jaký „druhý krok“ chcete při přihlášení použít. Jednou z možností je i bezpečnostní klíč:

Nelekněte se, že v popisu (zatím?) chybí klíč v telefonu

Poté si vyberete, jestli chcete používat externí USB nebo Bluetooth klíč, nebo ten vestavěný v mobilu, ve kterém jste přihlášení ke Google účtu:

Po zvolení možnosti používání vestavěného klíče v mobilu se dozvíte, že musíte mít zapnutý Bluetooth v mobilu i počítači, že telefon musí umět určit polohu (a musí mít Android verze 7 a novější) a že to funguje zatím jen v Chrome (a také v prohlížečích postavených na Chromiu jako Brave, Opera a nový Edge):

Kliknout na „Přidat“ a je hotovo, není potřeba párovat žádná Bluetooth zařízení, ani nic opisovat nebo potvrzovat v e-mailu:

Po návratu do nastavení se dozvíte, že bezpečnostní klíč je výchozí (je vhodné mít nastavené i další „druhé kroky“ pro případ ztráty telefonu např.) a že se používá ten v telefonu:

Přihlášení do Google

Po zadání jména a hesla vyskočí v Chrome okýnko, ve kterém vám radí se podívat na telefon, můžete také vybrat možnost externího USB klíče:

Na telefonu bude po odemčení zobrazen dotaz jestli se k uvedenému účtu pokoušíte přihlásit s možností „Ne, nejsem to já“ a „Ano“:

Když vyberete „Ano“, tak tím to končí a jste přihlášení. Pokud to budete provádět z nového zařízení nebo anonymního okna prohlížeče, tak vám nejspíš ještě přijde jeden dotaz na potvrzení zařízení. Na stránce Nedávno použitá zařízení se pak můžete podívat, kde všude jste k účtu přihlášení a případně některé stará již nepoužívaná zařízení odstranit. Doporučuji se tam občas podívat.

V případě, že se z nějakého důvodu potvrzení v telefonu nezobrazí, máte možnost použít další nastavený druhý krok.

Nastavte si 2FA

Fakt bych doporučil si dvoufázové ověření (2FA, 2SV, jak tomu budeme říkat je teď asi celkem jedno) nastavit a to i když používáte správce hesel (používáte, že jo?) – jako další úroveň ochrany. Pokud máte Android 7 a novější, tak tohle je krásná a vysoce použitelná možnost pro každého, snad se to rozšíří i do jiných systémů a aplikací. Google tvrdí, že potřebujete Windows 10, Chrome OS nebo macOS X, ale mě se „Zkontrolujte telefon“ zobrazilo i na Ubuntu 18.04. Na telefon nic nedorazilo, ale to může být tím, že Ubuntu běželo jako virtuální stroj.

Nastavte si také další „druhé kroky“ pro případ, že vám telefon kamsi odejde (nebo uplave). Jo a nezapomeňte tohle (nebo jinou pro všechny použitelnou metodu ověřování přihlášení) taky nastavit ve firmě, hned poté, co lidem rozdáte správce hesel.

E-mailové služby se za posledních 50 let téměř nezměnily – jedinou velkou změnou byla doba, kdy žačaly podporovat CSS. Nyní

Příspěvek E-mail klient Spike pochází z Spajk.cz

V posledních měsících se nám tu rozmohl takový nešvar. Jsou jím podvodné e-maily, které se snaží z uživatelů vymámit nějakou tu

Příspěvek Pozor na podvodné e-maily pochází z Spajk.cz

Telegram tento týden dost výrazně rozšířil možnosti mazání zpráv v rámci snahy o co největší soukromí uživatelů. Reakce však uživatelů jsou však zatím smíšené, kde leží hranice práva na mazaní online konverzací?

Telegram doteď umožňoval smazat jakoukoliv vaši zprávu na obou stranách konverzace do 48 hodin od poslání. To je funkce, která se pomalu stává standardem a začínají ji podporovat i služby jako Messenger nebo WhatsApp. Telegram ale zašel tento týden ještě mnohem dál. Umožňuje smazat jakoukoliv zprávu v chatu (i od protistrany) bez časového limitu. Dokonce kompletně celou historii kteroukoliv ze stran konverzace. To samé může udělat kterýkoliv z účastníků soukromého skupinového chatu.

Právě možnost mazat zprávy ostatních považuje část uživatelů za překročení hranice. Já osobně to tak nevidím. V online světě zanecháváme řadu soukromých a citlivých informací, ke kterým historie chatů bez debaty patří. Lidi dost často podceňují, co se může s takovými daty dít. Představte si, že veškerá historie chatů ve vašem oblíbeném komunikátoru je volně dostupná a pod vaším jménem vyhledatelná na Internetu. Asi to pro většinu z vás není úplně příjemná představa, že? Přitom se nejedná o úplně nereálný scénář. Velké úniky dat uživatelů se stávají v lepších rodinách. A bohužel v momentě, kdy se jednou vaše data uloží, už si často žijí svým životem, aniž byste to mohli nějak ovlivnit.

Takový WhatsApp sice dává od ukládání historie ruce pryč, ale umožňuje automatické zálohování na servery Googlu nebo Applu a vaše data skončí tam, aniž byste si to vůbec přáli. Stačí, když si to zálohování nastaví protistrana. A vy definitivně ztrácíte kontrolu nad vašimi daty.

Proto se mi líbí víc přístup Telegramu, který ukládá historii běžných chatů na svých serverech. Je to subjekt, na kterém se obě strany dohodly tím, že jej používají ke komunikaci. Neposílá data žádné třetí straně, s kterou nemusí jedna ze stran souhlasit. Pořád jsou ale data na serverech Telegramu. K žádnému úniku zatím nikdy nedošlo, ale nikdy nevíte. Kontrolu nad daty vám dává až možnost je kompletně smazat.

Otázkou zůstává, jestli by se to mělo týkat i zpráv protistrany. Můj osobní názor, že v případě dvoustranných chatů ano. V případě soukromých konverzací by mělo právo na smazání převažovat nad právem protistrany na archivaci. Pokud smažete jen své zprávy z chatu, pomůžete si pouze částečně. Protistraně i tak zůstávají možnosti. Sprovodit taková data ze světa kompletně je prakticky nemožné. Protistrana si je může vykopírovat, udělat screenshot, vyexportovat všechna svá data z Telegramu na disk. K tomu je potřeba ale určitá manuální práce, takže si nemyslím, že by se to dělo v nějakém větším rozsahu.

Kde si myslím, že Telegram šlápl vedle, je mazání celých chatů kterýmkoliv z účastníků. Takové chaty mají klidně desítky uživatelů a jeden z nich, aniž by se do konverzace třeba někdy zapojil, může historii smazat pro všechny. Stejně tak selektivní mazání starých zpráv protistrany může sloužit k manipulaci, takže tady bych se přikláněl k řešení „buď nic nebo všechno“.

Hledání ideální hranice je těžké, ale jsem rád, že se tím nějaká služba zabývá. Málokdo k tomu má motivaci. Pro některé služby je informační vytěžování dat uživatelů přímo součástí jejich byznysu, pro některé zase není soukromí uživatelů taková priorita.

E-mailem se aktuálně šíří vlna podvodných zpráv, které se Vás snaží nalákat na superhyperultra výhodné aukční nabídky. Kdo by nechtěl

Příspěvek Pozor na podvodné aukce pochází z Spajk.cz

Nedávno jsem potřeboval vyřešit poměrně jednoduchý problém. Rozbalit několik tarů obsahující adresářový strom. Jednotlivé archivy mají velikost řádově malé stovky GB, největší cca 300GB a obsahují několik stovek tisíc souborů.

Archivy obsahují adresářový strom se soubory, jejichž celkový počet je několik set tisíc, do milionu. Jsou uloženy v adresářích, kterých je několik málo desítek tisíc. Adresáře typicky obsahují max 100 souborů, průměrně mnohem méně. Nejedná se tedy o jeden adresář s milionem souborů, kde lze připustit, že by s tím mohl být problém (i když i to je poněkud zvláštní).

Úkolem tedy je tyto archivy někam (postupně) rozbalit, něco udělat s daty (to není předmětem tohoto článku) a potom ta data opět smazat. A rozbalit další archiv. Úloha je tedy poměrně přímočará: rozbalit, zpracovat, smazat, opakuj.

Pracovní dataset a pool

Vzhledem k tomu, že mám aktuálně nejvíce místa na ZFS na FreeBSD, tak jsem, nic zlého netuše, začal s touto akcí právě na ZFS. Dataset měl nastavený sync=disabled, nebylo potřeba data nijak chránit, v případě výpadku proudu a UPS lze daný archiv znovu rozbalit. Stejně tak je vypnutý atime a není použitá komprese. Tj. v zásadě nejrychlejší možné nastavení ZFS datasetu.

Zpool, na kterém tento dataset bydlí, je postaven jako 3x VDEV mirror, tedy ekvivalent raid 10 nad 6 disky. Sice se jedná o SATA 7200rpm disky, ale i tak se jedná o nejrychlejší možný zpool, kterého na daném stroji dosáhnu. Rychlost sekvenčního čtení 600MB/s, zápis kolem 450MB/s, 720 random read IOPS, 360 random write IOPS. Jasně, v době NVMe storage nic moc, ale na soukromé zpracování dat je to v pohodě.

Testovací archiv

V tomto článku budu jako testovací archiv používat následující:

Není to tedy nic, z čeho by se musel běžný FS zbláznit.

Testy na ZFS

Rychlost rozbalování nebyla nic moc, ale ještě to šlo vzhledem k tomu, že operace nad daty byla výrazně pomalejší, rozbalování příliš nezdržovalo.

Rozbalení dat na dataset se sync=standard:

A na datasetu s sync=disabled:

Zajímavý je ještě jeden údaj a to byl vlastně první důvod, proč jsem se na výkon ZFS z hlediska počtu souborů za čas zaměřil prve. V rámci práce potřebuju hledat soubory v daném stromu podle jména. Nic složitého, prostě jen find . -name 'filename'. Problém ovšem je, že to trvalo skoro tři minuty. Nebyl by to problém, kdyby to takto dlouho běželo jen poprvé, ale systém z nějakého důvodu ty metadata velice rychle (v rámci minut) zapomene. Netuším proč.

Zde je test find | wc -l pro oba datasety (prakticky by na to sync neměl mít vliv, protože je to čtení a ještě k tomu metadat):

Takže téměř pokaždé, když chcete udělat find (nad necelými 200tis soubory!) si počkáte přes dvě minuty. (Testovací archiv je skoro rok starý, pro aktuální dataset s více soubory je toto číslo ještě větší.)

Další a největší problém ale nastal u mazání tohoto pracovního stromu. Pro menší archivy (cca 30GB) byla rychlost rm -rf workspace dokonce pomalejší, než rozbalení archivu. Ano, vytvořit cca 200tis. souborů o celkové velikosti cca 30GB je pro ZFS jednodušší úkol než jejich postupné smazání.

Rychlost mazání pracovního archivu na ZFS:

Takže rychlost mazání je srovnatelná s rozbalováním archivu. Rychlost mazání souborů je necelých 100 / s na min. 360IOPS. Což je docela tristní.

Když bych si měl zaspekulovat (ale zcela jistě to takto není, viz další text), tak to vypadá, že i rychlost rozbalování archivu je limitovaná nikoliv rychlostí zápisu dat (ten zpool umí být 5x rychlejší), ale možná zápisem metadat pro každý soubor.

Při hledání na webu jsem narazil jen na obecné odpovědi typu prostě je to pomalé bez nějakého relevantnějšího výsledku.

Řešení, které se přirozeně nabízí, je vytvořit nový dataset, rozbalit tam archív a po zpracování tento dataset smazat. Tato operace je z hlediska userspace “hned” (při nastavení feature@async_destroy=enabled na daném poolu), ovšem ani zfs nemá příliš mnoho práce s uvolněním datasetu z poolu. Na rozdíl od mazání jednotlivých souborů.

Narazil jsem ještě na jedno další a hodně neintuitivní a zajímavé možné řešení. A tím je udělat clon daného datasetu, v tom clonu smazat ty soubory (pokud nechceme smazat celý dataset) a potom smazat původní dataset a jeho snapshot. Zdá se to jako blbost, FS musí mít víc práce se záznamy který blok do kterého clonu patří.

No ale vyzkoušel jsem to:

Takže mazání souborů z clonu je rychlejší (cca 4x) než mazání souborů z původního datasetu. Velmi zajímavé.

Obecně je dobrá rada používat všech vymožeností, které nám daný FS nabízí, takže pokud víme, že bude potřeba nějakou část dat rychle smazat, můžeme jej umístit na vlastní dataset (nebo obecně na vlastní FS) a vyřešit to tímto způsobem. Ale opravdu je nutné, aby rychlost mazání probíhala takto pomalu?

XFS na pomoc

Vrtalo mi to hlavou, tak jsem si vzal na pomoc linux a XFS, který po obrovské rekonstrukci v roce 2012 vynikající přednáška, umí s metadaty pracovat velmi rychle.

Takže jsem si vzal volný 3TB disk (stejného typu a rychlosti jako v zpoolu), udělal 320GB oddíl (disk dosahuje nejvyšší přenosové rychlosti na okraji, takže malé oddíly vytvářené na počátku disku jsou obecně velmi rychlé) a naformátoval na XFS bez jakýchkoliv dalších optimalizací. A na tento jeden disk (tj s třetinovou rychlostí zápisu oproti zpoolu) jsem rozbalil archiv. A nestačil se divit.

Všechny testy na XFS přehledně v jedné tabulce:

Zatímco na ZFS trvá mazání adresářového stromu cca 2000s, tady je to hotové za 57s, tedy 35x rychleji. A to ještě za situace, kdy XFS je na jednom disku, zatímco zpool tvoří de facto raid10 nad šesti disky a jeho výkon v zápisu by měl být 3x vyšší.

Grafy

Nejprve si ukažme srovnání rychlostí rozbalovaní archivu z hlediska počtů souborů za čas:

Pokud připustíme, že ZFS má k disposici 3x větší diskový výkon (což je z mnoha důvodů dost diskutabilní tvrzení a docela nefér srovnání), vypadalo by to následovně:

A konečně porovnání rychlosti mazání daného archivu:

Nefér srovnání rychlosti mazání zde nemá smysl uvádět, to by tam výsledky ZFS nebyly ani vidět.

Závěr

Vlastně to celé začalo docela nevinně, zkoumal jsem, proč je find nad těmito daty tak pomalý (Z hlediska FS se vlastně jedná o ideální stav, žádný adresář není přeplněný soubory, indexy jsou malé a rychlost procházení by měla být maximální. Ale není.). Na to jsem zatím nepřišel, jen mám seznam nepotvrzených hypotéz (například velký počet snapshotů nebo vůbec jejich přítomnost na datasetu). V rámci urychlení findu jsem testoval i vliv SSD cache. Bez výsledku, dokonce to bylo horší. Cache jsem nastavil pouze na metadata, viděl jsem (v zpool iostat) jen zápis. Nikdy ne čtení. Ten systém z nějakého důvodu zahazuje metadata adresářů z paměti i z cache.

Takže to jsem nevyřešil a objevil se další, větší, problém. Rychlost mazání souborů na ZFS. Na webu jsem našel jen odkazy „ano, je to pomalé, vyhněte se tomu“. A to je vlastně i poselství tohoto článku. Tento článek neměl být kritikou ZFS. Každý systém má své quirky a nevyhnou se ničemu a nikomu.

Výkon XFS je pozoruhodný. Srovnání není úplně fér, protože XFS je FS staré generace a ani omylem neposkytuje totéž co ZFS, to je nutné vždy brát v ohled. Asi se tady sešly dva extrémy, jeden FS, který má se změnou metadat problém a druhý, který to v roce 2012 vyřešil.

Rozmohl se mi na projektech takový nešvar. ‎Z různých důvodů provozáci nebo architekti klienta nepoužívají, nebo požadují od nás nepoužívat, připravené balíčky použité linuxové distribuce pro instalaci potřebných komponent (databáze, servery atd.). Vzhledem k tomu, že si (v českých podmínkách) neumím představit situaci, kdy by to byl rozumný kompromis prakticky s jakýmkoli jiným požadavkem, začal jsem blíže zjišťovat logiku takového rozhodnutí. Přišlo mi, že zatímco argumenty proti použití balíčku jsou velmi promyšlené konstrukce často nepřímých souvislostí, povědomí o přímých dopadech (resp. nákladech) takového rozhodnutí je spíše mlhavé. Prostě se stáhnou zdrojáky a udělá se .configure & make. To je bohužel naprosto tragicky naivní představa, kterou bych chtěl alespoň trochu poopravit.

Poslední pokus kontaktovat mnou volené zástupce v Evropském Parlamentu.

Valve nedávno uvedlo ve Steamu Proton pro spouštění her pro Windows na Linuxu, tak jsem si řekl, že to vyzkouším a vrátím se do nejlepších let svého herního života.

Počítač jsme doma měli od roku 1994. První roky to pro mě byl hlavně herní stroj. Prince of Persia, Prehistoric,… na Golden Axe jsem zničil klávesnici, protože se vylomily klávesy, kterými se sekalo. Postupně jsem začal na počítači dělat i jiné věci: školní časopis, od roku 2000 webovky apod. S pravidelným hraním jsem skončil v roce 2005, kdy jsem přešel na Linux.

Když před pár měsíc Valve oznámilo Proton pro hraní her pro Windows na Linuxu, nechávalo mě to docela chladným. Jako domácí počítač mám 5 let starý ThinkPad X240, který je všechno jenom ne herní. Nedávno jsem si vzpomněl na první hru, kterou jsem si koupil v krabicovém vydání: Mafii. A říkal jsem si, že tenkrát to sice byla pokročilá hra, ale přece jenom 17 let je v IT dlouhá doba a dneska by mohla jet pěkně i na tom mém notebooku.

Podíval jsem se na databázi kompatibility s Protonem a byla „Platinum“. Navíc byla Mafia na Steamu zrovna v akci za 6,99 eur. Tak jsem neváhal a koupil. Bohužel česká verze se nechtěla dostat přes úvodní dialog s nastavením. Anglická najela bez problémů. Přišel jsem tak o legendární dabing Marka Vašuta, ale nevadí.

Mafia jede i na tomto postarším notebooku jako z praku. Tak si k tomu občas večer sednu potom, co zbytek rodiny ulehne. Mafia byla jedna z prvních „free world“ her, na kterých se mi líbí, že umožňují originální řešení. Grafika už není žádný výstřelek poslední módy, ale jinak je i po těch 17 letech Mafia skvěle hratelná a zábavná. Sranda je, že i po těch téměř dvou dekádách se člověku začnou vybavovat detaily a ví, co na něj čeká. Někde v dlouhodobé paměti ty hry všechny ještě mám

Mafia I

Mafii 2 už jsem nikdy nehrál a s Protonem není očividně úplně kompatibilní. Co bych ale chtěl zkusit taky, je Max Payne. Ten je taky z té doby. Je sice víc lineární než Mafia, ale zase má skvělou atmosféru.

Třeba se časem posunu ještě o dalších 10 let dozadu k těm opravdu retro hrám pro PC, ale zatímco Mafia nebo Max Payne jsou i dnes docela atraktivní hry, originální Wolfenstein 3D a Doom už mi přijdou příliš jednoduché. Když jsem poprvé viděl Wolfenstein 3D, byl jsem úplně ukouzlený, protože to byla moje první 3D hra. Dnes už mě hra, kde pixely, z kterých je vykreslená zbraň, spočítám na prstech ruky, tak nebere

Wolfenstein 3D

Mimochodem máte tipy na ještě jiné hry, které můžu bez problémů provozovat na X240? Dost jsem ještě hrával Empire Earth, Age of Empires, Civilization, TTD, doslova jsem miloval X-COM: Terror from the Deep, ale při tom večerním hraní na odreagování preferuju spíš akční tituly.

Přepis (resp. původní textová verze) mojí přednášky z jOpenSpace 2018 na téma spolehlivosti software a komplexních systémů.

Balíme auto, nakládáme poslední věci a vyrážíme na InstallFest do Prahy. Přijďte tam za námi.

Je jaro a to znamená, že je tu InstallFest! Opět se vydáváme do víru velkoměsta a na tradiční linuxácké konferenci otevřeme svůj stánek. Sedněte na vlak, autobus nebo na svého draka a rozhodně si nechte tuhle akci ujít.

V prostorách budeme mít opět svůj vpsFree stánek, na kterém vám uvaříme vynikající kávu. Až ji budete popíjet, můžete si s námi popovídat o virtualizaci, serverech, Linuxu, open-source a mnoha dalších věcech.

Uvidíte náš nový switch, na kterých brzy poběží celý provoz mezi jednotlivými nody (servery). K vidění bude taky jeden náš server, kterých máme v datacentru celou hromadu. Určitě se za námi stavte: je to v sobotu a v neděli na Karlově náměstí v budově ČVUT.

Pokud se už nemůžete dočkat, podívejte se na loňské fotky.

Pár postřehů ze sobotní schůze a hlavně, co nás čeká v nejbližších dnech – změna stanov a přidání možnosti on-line hlasování.

Ahojte všichni,

ze schůze ještě bude záznam (o víkendu), ale na Tomsovo prezentaci nebyly bohužel moc dobře vidět fotky (to jsem sám zvědavý, jestli že záznamu uvidíme, čím se to opravilo…). Zatím se podívejte na fotky ze schůze.

Takže jsem nahrál všechny slajdy na web.

Tam je pěkně vidět, co jsme si naložili za TODO; největší bod k skoro okamžitému řešení je přidání online hlasování do stanov.

Podle aktuálních stanov, které jsou v rejstříku, jsme usnášeníschopní byli, ale jelikož jsme neměli připravenou žádnou dobrou formulaci a už vůbec nic lepšího nás nenapadlo na místě, pojďme připravit nad stávajícím zněním novou verzi, kde online hlasování bude zpracované – a další změny, pokud nějaké vlastně vůbec jsou potřeba, pojďme řešit online.

Ve stanovách aktuálně máme usnášeníschopnost schůze členů vždy – ale viděli jste sami účast, organizací hostující spoustu lidí, naději, snu a plánu, potom může pár lidí podle aktuální nálady na jednom místě, během pár hodin, i třeba nedopatřením, může nepromyšlená změna stanov šitá horkou jehlou velmi rychle poslat do existenciálních problémů – to nechceme, pojďme to tedy udělat relativně v klidu.

K řešení je jenom převod hlasování a zasedání Schůze a Mimořádně schůze na takový formát, aby se mohla udit v čase více rozprostřené, s projednáním většiny věci online;

Moje představa je následující:

1. pozvánka k mimořádně i pravidelně řádně svolané Schůzi bude muset obsahovat sice předběžné, ale srozumitelné formulované body k případnému hlasování

2. proběhne fyzické setkání, na kterém se odprezentuji všechny informace, které členové potřebují ke kvalifikovanému rozhodnutí, aspoň slajdy, ideálně záznamy se dostanou ke všem členům, i těm, kteří nebyli fyzicky

3. čas pro diskuzi na mailing listech

4. hlasování o konkrétním znění konkrétních bodů přes vpsAdmin (žádný nový bod nesmí v procesu přibýt, do hlasování půjde jen to, co bylo na úvodní pozvánce, jinak to potřebuje novou Schůzi)

5. konec Schůze

Otázkou je – jak Oskar (Ondra Caletka) správné řešil promptně hned na místě – jakým způsobem se dobrat k výsledkům, když už budeme mít nějaká vstupní data. Co považovat za správný výsledek, jakou metodiku zvolit při sčítání hlasů. To bychom se měli dost rychle rozhodnout a dohodnout

Ve stanovách máme aktuálně zakotvenou BDFL Radu i Kontrolní komisi (benevolent dictator for life, tj. s neomezeným volebním obdobím za podmínky, že to dělají dobře) – tedy pokud bude celočlenská Schůze o něčem hlasovat, půjde vždy relativně o významnou událost, protože když se má měnit tým, se kterým se počítalo, že bude stabilní, asi to nebude jen tak.

Je teda potřeba mít proces odolný vůči vyvolávání emocí z jakékoliv strany, jak to jen jde. Vyhrát musí vždy technický výborně a s ohledem na cíle organizace vždy nejlepší možné řešení, od toho vpsFree máme, aby nám něco společného pěkně fungovalo, ne abychom měli o čem se dohadovat

Pojďme tedy vymyslet co nejjednodušší, nejmenší zásah do Stanov, abychom umožnili přibližně aspoň takhle dobrý průběh Schůze, a tím i budoucí fungování.

Dostál jsem v sobotu od pětadvaceti z vás mandát hlasovat o změně stanov, písemně, s ústním porozuměním, že půjde o změnu stanov s ohledem na umožnění online hlasování.

Na 9. března bude také záznam a nejspíš i live stream, Adam z AVC se nechal hecnout a dojede do Brna.

Potřeboval bych vědět, kdo všechno přijdete – base48 není velký, vzhledem k účasti v sobotu v Praze jsem tipoval, že se zase sejdeme komorně tak v pěti lidech, kdyžtak prosím zaklikněte svoji účast v Doodle, ať připravíme aspoň trochu místa.

Díky moc všem, co jste přišli v sobotu – a díky všem, kteří mi věříte natolik, že jste se hecnuli tak, že mi dáváte bianco šek na měnění stanov – tahle důvěra pro mne osobně hodně znamená, s takovouhle podporou vím, že má smysl to dělat dál, ve větším – a ještě lip.

Díky ještě jednou.

A za týden a kousek v sobotu v Brně. Nebo kdo chcete, i dřív, v Base48 jsem skoro každý den…

Komu se zalíbilo v Brmlabu, kdo máte chuť si občas pohrát s nějakou elektronikou a podobně, neváhejte tam chodit – ještě se teprv napříč československými hackerspacy začnou dít věci, stojí za to, být u toho… víc info časem.

Pár posledních měsíců jsem ve volném čase prozkoumával potenciál jednoho nápadu na startup. Bylo to zábavné, zajímavé a poučné, ale nepodařilo se mi nakonec zkonstruovat byznys model robustní natolik, abychom do toho já a moji přátelé mohli jít naplno. Bylo by mi ale líto, kdyby celá ta snaha přišla úplně vniveč, takže dávám k dispozici klíčové poznatky a know how, které jsem získal a doufám, že třeba pro někoho mladšího, s menšími závazky to bude schůdnější. Zkuste pokračovat tam, kde já jsem ztratil dech.

Nedávno mi jeden klient otevřel oči, když pregnantně formuloval myšlenku, která je v retrospektivě zcela evidentní a pro dělání IT byznysu dost zásadní. Já si ji však nikdy explicitně neuvědomil a to přesto, že jsem se v jejím přímém vlivu v poslední době pohyboval hned několikrát. O co jde?