Používám jak GUI aplikace, tak ty textové a přestože mi tu běží Xka s KDE, trávím hodně času v konsoli a na příkazové řádce. Kombinuji tedy ovládání klávesnicí i myší podle toho, co je výhodnější. A říkal jsem si, že by se občas hodilo mít možnost přetáhnout soubor myší ze správce souborů (v KDE to je Dolphin) do příkazové řádky, kde mám rozdělanou nějakou práci a hlavně nalistovaný ten správný adresář. Příjemně mne překvapilo, že v KDE už tahle funkce je :-)

Když chce malíř vytvořit obraz (produkt) vezme štětec (nástroj) a namaluje ho. Jasné jako facka. Co ale vlastně dělá malíř, když vezme tužku a namaluje si nejdřív skicu?

V červnu rostla kategorie Cestování – prodej   tereza.tumova@… Pá, 07/05/2019 - 08:31

Jak přidat webové aplikaci REST API s knihovnou API Platform ....

Většina lidí bilancuje poslední den roku, ale včera jsem neměl čas, protože jsem něco programoval, tak napíšu bilanci dneska, na Nový rok večer. Bude však o to delší a snad i zábavnější :-)

Rok 2018 byl pro mě spíš takovým pokračováním roku 2017, který byl na události mnohem nabitější. A co teprve rok 2016 nebo dokonce 2015? Každý byl docela úžasný. Mám-li ale své současné bastlení popsat chronologicky, musím zřejmě začít ještě o kousek dřív...

2014

V roce 2014 jsem už naplno dělal s Arduiny, ale brzy měl až po krk vrabčích hnízd v breadboardech a chtěl jsem začít pájet hotové výrobky. Na to jsem ale potřeboval nové místo - pájecí stůl, a tak jsem si ho v červenci pořídil:

V září 2014 jsem pak na podomácku děsivě vyleptaném plošném spoji postavil první prototyp PARCP-USB.


O měsíc později jsem už osazoval profi plošné spoje (první z Číny), a dnes má PARCP-USB doma nejeden Atarista.


V prosinci 2014 jsem postavil předchůdce WiFi Teploměru, tenkrát ještě s Ethernetovým rozhraním. Už tehdy jsem měl doménu teploty.eu (později jsem přešel na teploty.info) a začal pracovat na ukládání naměřených hodnot a grafech teplot.

2015

V únoru 2015 jsem kamarádovi postavil chytrý dům - ovládání světel a žaluzií přes tablet, všechno po OneWire sběrnici. Tu jsem měl v té době už mimořádně oblíbenou.


V květnu 2015 jsem vytvořil USB adaptér pro původní 8bitové joysticky, pro dokonalý retro zážitek při hraní Atari her nejen na mém Atari800 emulátoru.


V červenci 2015 jsem postavil něco jako USB voltampérmetr s Arduinem a displejem (měl jsem pak o něm na OpenAltu přednášku).


V září 2015 pak vznikl na detailní zakázku první (spíš nultý :) kus WiFi Teploměru, což v budoucnu nečekaně ovlivní můj život, priority, volný čas a podobně.


Poté jsem si koupil první trochu "profi" vybavení na můj pájecí stůl - digitální multimetr (starý z dětských let už dosluhoval) a krásný 4kanálový 100MHz osciloskop, který skoro nepoužívám, ale když už ho někdy potřebuju, je vskutku nenahraditelný.


V listopadu 2015 jsem pro jednu nejmenovanou firmu vytvořil "informační systém" z kombinace Raspberry Pi a velké LCD TV. Mají to nasazeno ve výrobě a funguje to spolehlivě už tři roky (klepu na dřevo).


Zajímavostí je obrovský panel o FullHD rozlišení složený ze čtyř velkých TV, na který se promítá obraz (čtvrtina obrazu automaticky na každou televizi). Celková úhlopříčka skoro 3 metry.

2016

V lednu 2016 jsem začal stavět "digitální vodoměr" (optický odečítač hodnoty z klasického vodoměru s točícími se kolečky), samozřejmě s pomocí Arduina.


V březnu 2016 jsem na InstallFestu osobně potkal jednoho ze jmenovců, který mi zabral doménu petrstehlik.cz :-) Stehlík, nebo dokonce Petr Stehlík, se dnes ostatně jmenuje prakticky každý programátor, grafik nebo bastlíř. Je to těžké :-)


Zároveň jsem řešil umírající zapalování plynového kotle. Nejdřív mě asi půl roku zachraňovalo resetítko postavené z Arduina, ale nakonec jsem vyměkl a koupil novou zapalovací elektroniku.


2. dubna 2016 jsem byl na významné události: schůzce Zlínského Atari klubu po 30 letech (dávám to sem pro pobavení, vypadá to jako skoro klub důchodců - a prakticky je! :-)


V květnu 2016 jsem postavil první sériový kus WiFi Teploměru, protože jsem si říkal, že je škoda zahodit tu práci a zkušenosti, které jsem nabral při stavbě prvního prototypu podle zadání Kamila Z. Od té doby jsem vytvořil nejméně 15 revizí plošného spoje, přešel z kupovaných ručně vrtaných na přesné 3D tištěné krabičky, vymyslel mnoho nových čidel, párkrát přepsal firmware - zkrátka mě baví pořád to vylepšovat.


Bohužel se ale v té době začal o slovo hlásit dům, že chce po 16 letech nějakou tu údržbu. Nejdřív v červenci 2016 rekonstrukce koupelny:


Přitom se ukázalo, že špatně propojený odpad od umyvadla nechával roky téct odpadní vodu do základů dřevěného domu. To bylo hned starostí s hnilobou nosných trámů, vyháněním mravenců z konstrukce domu, sháněním specializované vysoušecí firmy, půlroční boj s pojišťovnou a podobné radosti.


Koncem října jsem postavil nádherné police ve sklepě, které byly určeny pro nedočkavě očekávanou, dlouho složitě vybíranou novou 3D tiskárnu. Bohužel volné místo bylo okamžitě zaskládáno nesouvisejícími věcmi, takže tiskárna ve sklepě nikdy nebyla, smrdí mi v pracovně :-)


V listopadu 2016 přijela první tiskárna Průša i3 MK2. Od té doby mé elektronické výrobky mají konečně nějakou rozumnou podobu. Co posledních 30 let vypadalo vždycky jako vrabčí hnízdo, má nyní krásnou krabičku. A co věcí v domácnosti umí 3D tisk vyrobit či opravit! 3D tiskárna patří do povinné výbavy každého bastlíře...

2017

V lednu 2017, ve velkých mrazech, padlo roky odkládané rozhodnutí vyměnit plastová okna za nějaká s nepromrzajícími rámy (ano, vevnitř v místnosti opravdu naměřím mínus pět stupňů Celsia na rámu okna).


Začátkem února 2017 jsem si koupil v českém obchodě z Polska čínskou pájecí stanici, která má horký vzduch i páječku. Horký vzduch mi od té doby mnohokrát pomohl odpájet či zapájet mikrokontroléry, zatímco páječku jsem na naléhání přátel z G+ začal používat až teprve v srpnu 2018 (a dobré!)


V únoru 2017 mi taky praskl plastový filtr na přívodu vody do domu a proud vody o tlaku 6 atmosfér mi za tři hodiny kompletně vyplavil sklepy a zničil spoustu věcí za mnoho a mnoho peněz.


Následné vysoušení odbornou firmou mi pak dodatečně zničilo ještě i podlahy (popraskaly potěry). Celkové škody v ceně nové Škody...


Na základě tohoto nesmírně silného zážitku (to fakt nechcete zažít podruhé) jsem hned v březnu dokončil optické odečítání průtoku vody a hlavně jsem na vstupu vody do domu přidal Arduinem ovládaný ventil, který při nadměrném či dlouhodobém průtoku vody všechno zastaví. Výsledné řešení jsem později prezentoval na OpenAltu.


V březnu 2017 jsem pro jednoho člověka dokončil na zakázku vyvíjenou USB nabíječku ze střídavého 24V napětí určenou do chatiček v jakémsi rekreačním areálu. Bohužel, nikdy si hotové zařízení neodebral, takže několikaměsíční vývoj se nezaplatil.


Též jsem v té době zkoumal, šlo-li by k běžnému čidlu kouře (požáru) připojit nějakou vysílačku a zapojit ji na internet, abych o případném vzniku požáru věděl, i když nejsem doma. Když jsem to konečně vyzkoumal, čidlo umřelo (asi sešlo věkem, po 10 letech odcházejí všechny).


V květnu 2017 jsem po mnoha letech bezdrátového internetu přešel zpět na DSL, tentokrát už VDSL2. S tím se pojilo mnoho velmi silných zážitků, které by vydaly na samostatný blog post. Teď, po dalším roce, si to už konečně "sedlo" a mám doma 100 Mbps, tak jsem rád. Každopádně mi zbyl úplně nový WiFi klient (původní v zimě 2016/17 po pěti letech odešel, tak jsem na tři měsíce koupil nový Mikrotik).


30. května 2017 jsem se po 18 letech rozloučil s plynovým kotlem (do kterého jsem půl roku předtím musel koupit novou zapalovací elektroniku) a bojlerem. Konečně jsem přešel na plně elektrický dům, jak jsem si posledních 10 let plánoval a pořád propočítával, jestli to vyjde nebo nevyjde lépe než plyn (první rok vyšlo, ale teď kvůli tomu zdražují elektřinu o 27 %, takže opět slepá ulička).


V srpnu 2017 jsem měl funkční vlastní svinovací vynález na zastínění terasy na nové pergole. Slíbil jsem na G+, že to popíšu/nafotím atd., ale ještě jsem neměl čas...


V září jsem na volné místo po plynovém kotli postavil stupínek pro krbová kamna. Naučil jsem se omítat a oprášil si pokládání a spárování dlažby.


27. září 2017 začala obávaná výměna všech oken v domě:


Aby toho nebylo málo, hned začátkem října jsme sbalili laminátovou plovoucí podlahu (po 18 letech stále jako nová) a zkusili místo ní nalepit lino (nebo PVC, nebo jak se to vlastně jmenuje). Cílem bylo dát podlahovému topení větší šanci hřát. Zatím se zdá, že to byl dobrý krok...


V listopadu 2017 jsem postavil dlouho plánovanou revoluční DC-DC UPS, samozřejmě s Arduinem. Dodneška jsem neměl čas ji zdokumetovat a publikovat :-[


V prosinci 2017 jsem pak začal stavět další dětský pokoj přepažením chodby pomocí dvojitých zasouvacích dveří. To mi pak umožnilo oprášit i mé sádrokartonářské schopnosti (které jsem nikdy moc neměl :-)

V tu dobu (konkrétně tuším 14.12.) jsem také po mnoha letech váhání konečně zainvestoval do bitcoinu. Od toho dne hodnota bitcoinu začala prudce klesat a dnes, po roce, je na méně než pětině původní hodnoty.

2018

Konečně jsme se dostali k aktuálnímu, tedy právě uplynulému roku! :-)

V lednu 2018 se rozbilo otevírání střešního okna Roto v novém dětském pokojíčku tak, že nešlo zavřít (proč se to děje vždycky v třeskuté zimě, jako se pokazilo zapalování plynového kotle, jako praskla voda a udělala povodeň ve sklepě?). Nechali jsme se přemluvit na kompletní výměnu obou oken, prý je to nejrozumnější varianta. A že prý to byla moje chyba, měl jsem je pravidelně mazat.


V březnu 2018 přijela nová 3D tiskárna Průša i3 MK3, protože jsem jako naprostý začátečník podlehl sugestivní reklamě a vyměnil ji za 100% funkční i3 MK2 (a pak jsem si pár měsíců trhal vlasy - ale už jsme si na sebe zvykli).


Na výstavě Ampér v Brně jsem si vybral své příští auto - Tesla Model X. Zmocnil se mě totiž neodbytný pocit, že budu brzy potřebovat šestimístné rodinné auto. Jen tento nadupaný model stojí skoro 3 miliony, takže budu muset ještě "pár let" šetřit :-)


Stále ještě v březnu 2018 jsem měl doma půjčenou sadu od Velkého klauna na zkoušku a recenzi - nafotil jsem a natočil mnoho materiálu, ale ještě jsem neměl čas to zpracovat do nějakého blog postu, sorryjako :-(


V červnu jsem instaloval tepelné čerpadlo k bazénu koupené na Silvestra.


V červenci jsem začal stavět hůru nad parkovacím stáním, protože potřebuju další prostory pro věci, které se doma neustále kupí. Opět jsem zvolil jako materiál Durélis, velké plotny spojené na pero-drážku, moc dobře se s tím dělá.


Tu hůru jsem sice dodělával až do Vánoc, ale druhou půlku stínění terasy jsem dokončil ještě v první polovině letních prázdnin:


Největší radostí roku 2018 je ale rozhodně narození mé jediné dcery. Dokonce jsem byl první na světě, kdo ji držel v náručí, heč :)


Abych to patřičně oslavil, jel jsem hned z porodnice do Valašského Meziříčí na sraz elektroaut, nechat se svézt v Tesle Model X (jak jinak :) nějakým usměvavým dobrovolníkem:


Koncem srpna je ve Zlíně každoroční Barum Rally, v roce 2018 byla podruhé i soutěž elektromobilů. Samozřejmě jsme si nenechali ujít prohlídku vítězného auta za předchozí rok - Tesly Model X (už chápete, který elektromobil je nejlepší, že? :)


V té době jsem taky, abych rychleji naspořil na vysněnou Teslu, začal naplno investovat na burzách cenných papírů - začal jsem skupovat akcie technologických firem. Kteroukoliv firmu jsem si vybral, jakkoliv věhlasnou, obrovskou, s desítky let dlouhou historií - jakmile jsem koupil její akcie, šla jejich hodnota prudce dolů. Koupil jsem několik dobře známých titulů (Microsoft, Intel, ...) a pokaždé se situace opakovala, takže to nemůže být náhoda :-) Rčení "prodělal i kalhoty" ani plně nevystihuje, čeho jsem dosáhl za pouhé tři měsíce :-D

V září mi kamarád na 2 týdny půjčil elektrické auto (starší Nissan Leaf), abych si ověřil, že je to skutečně nejlepší způsob pohonu osobních vozů a že auto se spalovacím motorem už opravdu nechci. Dobře se mi s ním jezdilo, do práce i po výletech! :-)


No a v říjnu, se zimou na krku, jsem začal opravovat rozpadající se dlažbu na terase u bazénu. Všichni přizvaní odborníci řekli jednoznačně "vykopat a udělat celé znovu", což by stálo šestimístnou částku. Takže jsem si to zkusil opravit po svém - pracně vyrýpat starou spárovačku a spáry znovu zalepit, ale tentokrát polyuretanovým tmelem.


Při tom všem jsem ještě dokončoval jeden tajný vládní projekt, o kterém vám nemůžu napsat víc, protože bych vás pak hned musel zastřelit, abyste to nevyzradili. Snad jen, že to byl můj zatím nejsložitější plošný spoj a že výsledek dopadl dobře.


V listopadu, když už mi hustý déšť mrzl za krkem, se rozpadla i dlažba před vstupem domu. I tu jsem jaksi opravil polyuretanovým tmelem.


Ještě by stálo za zmínku, že jsem začal pravidelněji navštěvovat Atari a podobné retro akce, takže jsem se krom jiného objevil i v podzemním protiatomovém bunkru pod zlínskou Poliklinikou, o kterém jsem celý život neměl nejmenší tušení. Zkusíme nastartovat muzeální elektrocentrálu?


No a to je tak zhruba vše, co mi fotky za poslední roky připomněly.

Pokud byste potřebovali využít některé z mých extra schopností, třeba postavit a omítnout nějakou zeď, nebo vztyčit sádrokartonovou příčku, položit dlažbu nebo položit nějakou firmu přes nákup jejích akcií či srazit kryptoměnu tak, že už se nevzpamatuje, jsem k dispozici :-)

Za loňský rok jsem se taky hodně naučil o elektromobilech a firmě Tesla, tak kdyby si někdo chtěl koupit nějaké vozítko, co nevrčí a nesmrdí, jděte do toho, je to super. Já budu ještě "chvilku" muset šetřit, vždyť víte... :-)

Mějte úspěšný nový rok 2019 a těšte se na další zprávy z mých komunikačních kanálů :)

P.S. taky jsem koupil 10" Android tablet a nestihl napsat recenzi. A o Vánocích jsem pro vás natočil super video, které nemám čas sestříhat... A určitě by se toho našlo ještě mnohem víc :)

P.P.S. kdyby někdo hledal odkazy na výše zmíněné přednášky, tak https://pstehlik.cz/prezent/

Venku je hezky a spousta lidí se sjela (nebo byla svezena) do Prahy, místo aby byli třeba někde u vody, a protestují proti vládě. Ale proč? Proti čemu a za co? V čí prospěch? Nad tím by se měl každý zamyslet sám. Já k tomu napíšu jen pár poznámek v bodech.

Index digitální ekonomiky a společnosti (DESI) 2019 tereza.tumova@… Út, 06/18/2019 - 13:27

Tzv. QR kódy slouží k šíření nějaké digitální/textové informace v podobě obrázku. Obvykle se používají v AFK světě – tisknou se na papír, dávají na různé krabice, výrobky, plakáty atd. a následně se skenují – většinou mobilem (např. 1, 2,

Celým detektivním seriálem ([1], [2], [3]) o nepříliš výkonném ZFS na FreeBSD se line jedna myšlenka. Zda náhodou ZFS nebo ioscheduler ve FreeBSD neomezuje rychlost (možná záměrným vkládáním sleep) IO procesu, aby zabránil přetížení systému a nedostupnost dat pro ostatní procesy.

To zcela logicky vede k myšlence, zda by nešlo číst data paralelně ve více procesech. To se snadněji řekne, než udělá. Pokud potřebujeme data rychle zkopírovat jinam, žádné paralelní cp nebo tar neexistuje (rozhodně není automaticky dostupné na běžných systémech).

Čistě pro test jsem si takový paralelní cp napsal (pomocí Python Multiprocesing Pool . map). Je to takové udělátko pro paralelní zpracování pole:

pool = Pool()
pool.map(fce, data)

kde fce je nějaká funkce akceptující argument a data je pole dat (v mém testovacím případě pole souborů). Map spustí fce (v mém případě shutil . copyfile()) nad každým prvek vstupního pole. Pool() tuto běžnou funkci (map, filter, reduce zná asi každý) umí spustit paralelně, ve výchozím stavu v počtu procesů podle počtu procesorů. Parametrem lze počet procesů určit. Tyto nástroje nám umožňují si snadno napsat test paralelního čtení.

Pojďme se, bez dalšího zdržování, podívat na výsledky. Jako testovací dataset posloužil můj pracovní dataset se soubory o velikostech cca 1MB s rozptylem až do 10MB.

Jak vidíme, test čtení v jednom procesu je pomalý, jen 17.5MB/s. S vyšším počtem procesů rychlost poměrně rychle stoupá a postupně se asymptoticky blíží limitě. Mimochodem, v minulém článku jsem teoreticky vypočítal rychlost čtení souborů o velikost 1MB a dostal jsem se k číslu 75MB/s. Dnešní test čtení ukazuje limitu někde kolem 70MB/s (v datasetu jsou ale soubory různých velikostí s průměrem 830kiB).

No jo, ale co teda s tím? Na jednu stranu je fajn, že se systém běžným používáním nenechá zablokovat a všechny ostatní procesy se ke svým datům dostanou bez ohledu na další provoz na FS, na druhé straně asi není dobré mít k disposici jen cca 25% výkonu v případě, kdy např. potřebujeme zkopírovat pracovní data na jiný disk nebo systém. Jistě, můžeme si napsat speciální nástroje, ale i to má svá rizika (viz varování v dokumentaci modulu shutil) – tzn je nutné řešit speciální soubory, práva, ACL, symlinky a hardlinky, sparse file apod. Jistým řešením může být vhodné rozdělení datasetu a paralelně tarovat jeho různé části. Ovšem ne vždy je toto možné udělat.

K vytvoření tohoto článku mě inspiroval kamarád na Facebooku, který udělal něco, co by podle mě dělat neměl. Neudělal to

Příspěvek Jak chránit soukromí dětí na internetu pochází z Spajk.cz

Určitě se Vám někdy stalo, že jste potřebovali aby Váš počítač běžel, ale on se po nějaké době zamknul, nebo

Příspěvek Jak zabránit počítači aby se uspal nebo zamknul pochází z Spajk.cz

Připravujeme se postupně na přechod na novou kontejnerovou platformu vpsAdminOS. S tím souvisí také systém šablon.

Na stagingu je nyní podporováno openSUSE Leap 15.1 a Tumbleweed, Slackware 14.2 a Void Linux (glibc, musl).

Poslední dva týdny jsem se snažil vylepšit situaci ohledně sestavování šablon distribucí, ze kterých se vytvářejí nové VPS. Od roku 2014 používáme k sestavování šablon skripty build-vpsfree-templates. Už tehdy bylo cílem šablony sestavovat pravidelně a automatizovaně, jenže se to nikdy nedotáhlo do konce. Šablony nestačí jen tak sestavit a hned je používat, protože distribuce se mění a skripty nemusí fungovat spolehlivě. Každá šablona se před použitím musí otestovat, a to se muselo vždy dělat manuálně.

Pokud chtěl někdo přispět, musel řešit kde a jak šablony sestavovat a testovat. Bylo nutné manuálně nainstalovat potřebné závislosti jako debootstrap, yum/dnf, zypper, atp. Na opravdové ověření funkčnosti bylo potřeba si nainstalovat OpenVZ.

Aktualizace šablony jedné distribuce spočívala ve zprovoznění skriptu samotného, výsledek si nakopírovat na nějaký systém s OpenVZ, pak z toho vytvořit VPS, zjistit že něco nefunguje (start, ssh, konzole, heslo, …) a zase na začátek. S uvedením vpsAdminOS se všechno muselo dělat dvakrát, protože se šablony samozřejmě liší.

Ve výsledku se šablony aktualizovaly jen když to bylo nezbytně nutné. U stabilních distribucí jako Debian to nevadí, s aktualizací systému po vytvoření VPS není problém. Rolling-release distribuce jako Arch nebo Gentoo jsou na tom hůře a po delší době dá aktualizace více práce.

Proto jsem se snažil to aspoň na vpsAdminOS udělat lépe: zajistit stejné prostředí pro sestavování šablon a automatizovat testování. Nix a vpsAdminOS jednotné prostředí zajistit umí. Toho jsem využil a program pro sestavování šablon jsem přidal přímo do OS. K sestavení šablon tedy stačí nabootovat vpsAdminOS, třeba v QEMU. Poté naklonovat skripty pro šablony na vpsAdminOS:

$ git clone -b vpsadminos https://github.com/vpsfreecz/build-vpsfree-templates.git
$ cd build-vpsfree-templates

Program, kterým se šablony sestavují, se jmenuje osctl-image. Sám o sobě žádnou šablonu sestavit neumí, funguje ve spolupráci se skripty výše, a očekává je v pracovním adresáři. Seznam šablon dostupných k sestavení zjistíme takto:

$ osctl-image ls

Pro sestavení šablony je potřeba libovolný ZFS dataset. V konfiguraci pro QEMU je automaticky k dispozici zpool tank, takže můžeme použít např. tank/image-builds. Sestavení vybrané šablony pak vypadá takto:

$ osctl-image build --build-dataset tank/image-builds ubuntu-18.04

Sestavené šablony se ve výchozím stavu ukládají do ./output. Sestavenou šablonu můžeme jednoduše otestovat:

$ osctl-image test --build-dataset tank/image-builds ubuntu-18.04

Aktuálně se testuje: start/stop VPS, síť, nastavení hesla roota, hostname a připojení přes SSH. Chtělo by to ještě testovat i funkční konzoli a přihlášení.

Pokud něco nefunguje, můžeme si snadno ze šablony vytvořit VPS:

$ osctl-image instantiate --build-dataset tank/image-builds ubuntu-18.04

Příkaz výše vypíše ID VPS, na kterou se můžeme podívat:

$ osctl ct start -F instance-abcdefgh
$ osctl ct attach instance-abcdefgh

Když je vše v pořádku, je čas na pull request. My šablonu přídáváme do repozitáře, ze kterého si ji vpsAdminOS stáhne při vytváření nové VPS:

$ osctl-image deploy --build-dataset tank/image-builds ubuntu-18.04 /kde/je/repozitar

Takto se staráme o výchozí repozitář na adrese images.vpsadminos.org.

Celý postup se dá shrnout do toho posledního příkazu, protože osctl-image deploy šablonu když je potřeba automaticky sestaví, otestuje, a až pokud je vše v pořádku, přidá ji do repozitáře. Podobně fungují i příkazy test a instantiate, proto je všude použito --build-dataset, aby se šablona mohla případně sestavit. osctl-image na pozadí spravuje VPS pro sestavovaní i testování šablon, jak to přesně funguje je popsáno v manuálu.

Abychom s tím měli dlouhodobě co nejméně práce, připravil jsem Nix modul, pomocí kterého lze deklarativně nastavit pravidelné sestavování repozitářů a jejich obsahu. Výsledek si můžete prohlédnout ve vpsfree-cz-configuration.

Máme to nastaveno tak, aby se šablony sestavovaly jednou týdně v sobotu ráno. Ty, které se podaří správně sestavit a otestovat budou ihned přidány do repozitáře. Pokud něco selže, pošle se nám mail s cestou k logu, ve kterém zjistíme co a proč se stalo. Uvidíme na co ještě narazíme, ale zatím to vypadá, že by to mohlo fungovat.

Výkonná rada SPIR opět potvrdila Michala Hanáka na postu předsedy tereza.tumova@… Pá, 06/07/2019 - 13:46

TL;DR je, že migrace produkčních VPS je stále daleko, ale spuštění produkčního node jsme blíže. Postupně vylepšujeme staging, odstávky už nejsou tak často a poctivě je hlásíme dopředu. Kdo chce nebo potřebuje, VPS už tam může provozovat. Produkce to ale stále není.

Padající vpsAdmin

Na únorové schůzi jsem zmiňoval, že nám na vpsAdminOS nehorázně často padá vpsAdmin. A to na segfault v ruby, nic z čeho by se dalo zotavit. Bohužel to padalo vždy při ukládání výsledku vykonaných operací, což pak vedlo k tomu, že se vykonávaly vícekrát a vznikaly tak nesmysly na disku i v databázi. Nakonec se mi to podařilo vyřešit aktualizací všech komponent, zejména mysql connector byl v nixpkgs v nějaké zapomenuté verzi. Teď to… sice taky občas padá, ale ne tak často a ne v tu nejhorší chvíli.

NFS na stagingu

Další nekonečný příběh je zpřístupnění nasboxu, nebo obecně NFS. V čem je problém: VPS používají user namespace, tzn. váš root z VPS nemá na nodu uid 0, ale nějaké jiné číslo. Z pohledu nodu je to neprivilegovaný uživatel a jako superuživatel se tváří jen ve VPS. To taky znamená, že pokud připojíte NFS export, na NFS server chodí UID/GID z VPS tak jak je vidí node, čili jako neprivilegovaní uživatelé. Proto i na NFS serveru mapujeme UID/GID na vašich datasetech, aby to sedělo s user namespace ve VPS.

V březnu jsem ve vpsAdminu dokončil implementaci správy user namespace, nastavování map u datasetů a mounty. Hned jsem to chtěl vyzkoušet a šel datasety na nasboxu exportovat i na adresu node1.stg… No a byl z toho několikahodinový výpadek. Exporty na NFS serveru se mění jeden po druhém, takže každý bude mít krátký výpadek a jede se dál, že? Bohužel ani náhodou. Nevím čím to je, ale když takhle hromadně měníte exporty, NFS server přestane obsluhovat klienty. Všechny klienty. Ani po zastavení operace server nezačal klienty obsluhovat, takže panika, restarty NFSD a znovu všechno exportovat… Ponaučení: více trpělivosti a nesahat na exporty bez nahlášené odstávky někdy v noci. Jinak by stačilo chvíli počkat a server by začal pracovat, prostě to jen dlouho trvalo.

Po téhle bitvě to nakonec na stagingu stejně nefungovalo správně. Protože root z VPS byl na NFS serveru co? Neprivilegovaný uživatel. Jako neprivilegovaný uživatel neměl oprávnění pracovat se soubory jiných uživatelů, atd. Prakticky nepoužitelné. Zde se nabízejí dvě řešení: NFS klient musí posílat UID/GID tak jak je vidí VPS, na NFS serveru by tak root byl privilegovaný uživatel. Druhá možnost by byla nastavit NFS server tak, aby určité neprivilegované UID bral jako privilegované.

Protože jsem v tu dobu nenašel žádnou aktivitu vývojářů NFS v tomhle ohledu, rozhodl jsem se implementovat tu druhou variantu, neboť mi přišla jednodušší. Výsledkem je nový parametr u exportu root_uid, což by se nastavilo podle mapování roota v jednotlivých VPS:

zfs set sharenfs=“root_uid=666000″ storage/vpsfree.cz/nas/…

Potíž je, že to vyžaduje patch kernelu i patch nfs-utils v userspace. Funguje to pěkně, jenže na nasboxu není vpsAdminOS. Sice by to šlo napasovat i na OpenVZ, ale rozhodli jsme se rovnou přejít na vpsAdminOS. Protože nasbox používá kolem 700 VPS, nejdříve jsme si vpsAdminOS vyzkoušeli na backuperu, který v tomto ohledu není tak důležitý.

Jeden problém s NFS při startu systému jsme skutečně odhalili a snad i opravili. Jinak to funguje velice pěkně. nasbox je další na řadě.

Bohužel se to teď zase komplikuje, protože do Linuxu 5.2 přistály patche, které implementují tu první možnost: UID/GID překládá už klient a na server chodí tak jak je vidí VPS. To je pro nás velká komplikace a než se k něčemu rozhodneme, musíme to vyzkoušet. Z NFS na stagingu tedy ještě nějaký měsíc nic nebude.

br_netfilter

Někdo se na IRC ptal na br_netfilter, který v Linuxu nepodporuje namespace a ve VPS tak nejde používat. Existuje ale patchset, který to implementuje. Do našeho kernelu jsme tento patchset přidali, nicméně… nevím k čemu se to používá, vím akorát že to používají nějaké aplikace v dockeru. Pokud to někdo potřebujete, řekněte nám prosím na co a jak je to důležité. Jinak není vyloučeno, že to budeme muset pustit, pokud se to nedostane do upstreamu.

Linux 5.0, 5.1, ZFS

Na stagingu průběžně přecházíme na nové verze kernelu. V produkci pak počítám že na delší dobu zakotvíme na nějakém LTS kernelu. Pro naše patche kernelu jsme vytvořili repozitář na GitHubu.

Mohli jste zaznamenat, že Linux 5.0 omezil export funkcí pro práci s FPU na GPL-only a odstřihl tak ZFS on Linux. Tímhle si nehodláme komplikovat život, ani snižovat výkon. Ten export jsme si v kernelu patchnuli, stejně jako to pak udělal i NixOS.

V pátek jsme přešli na Linux 5.1 a ZFS on Linux 0.8.0. ZoL 0.8 je opravdu parádní vydání, doporučuju se podívat na novinky.

/sys/devices/system/cpu/online

… používají některé aplikace na detekci počtu procesorů, aby věděly kolik mají používat vláken, workerů, apod. Tyto údaje v Linuxu nejsou nijak virtualizované a řeší se to v userspace pomocí LXCFS. Co všechno máte ve VPS „virtualizováno“ přes LXCFS zjístite s:

grep lxcfs /proc/mounts

V pátek jsme nasadili verzi LXCFS, která řeší i
/sys/devices/system/cpu/online. Používá to např. Python když zavoláte multiprocessing.cpu_count().

pty-wrapper

Aby měly všechny VPS otevřenou konzoli, pouštíme je ve wrapperu, který přichystá pseudoterminál a pak zprostředkovává komunikaci mezi osctld ve vpsAdminOS a vzdálenou konzolí ve vpsAdminu. Původně jsme tento program měli napsán v Ruby, jenže to na každou VPS zabíralo cca 15 MB paměti, které se účtovaly k zabrané paměti VPS. Sorki to přepsal do Haskellu a jsme teď na 5 MB na VPS.

Deklarativní konfigurace ZFS datasetů

Při instalaci nodu je potřeba nastavit ZFS properties, jako např. zapnutí komprese, nebo vytvořit nějaké datasety na zpoolu. Vše je teď možné deklarativně nastavit v konfiguračních souborech, abychom na nic nezapomněli.

Parametry kernelu

Kernel má spoustu hejblátek, které omezují určité prostředky, jako velikost ARP tabulky, inotify, kernel keyring a počty procesů. Právě na maximální počet procesů jsme na node1.stg nedávno narazili. Pokusil jsem se s tím udělat pořádek a vpsAdminOS nyní obsahuje doporučené nastavení těchto voleb.

Zjednodušení vytváření kontejnerů

vpsAdminOS původně vyžadoval manuální správu mapování UID/GID v user namespace. Na stagingu to za vás řeší vpsAdmin, ale v OS samotném to bylo zbytečně komplikované. Aby šel vytvořit kontejner, muselo nejdřív existovat ono mapování:

osctl user new –map 0:666000:65536 myuser
osctl ct new –user myuser –distribution ubuntu myct

Nově je nastavení UID/GID map volitelné. Ve výchozím stavu se pro každý kontejner alokuje unikátní blok UID/GID z definovaného rozsahu. –user se tak vůbec nemusí používat a stačí:

osctl ct new –distribution ubuntu myct

Díky tomu jsou od sebe kontejnery automaticky odděleny a zároveň to není žádná práce pro uživatele navíc.

nixos-modules

Máme už celkem dost konfigurace a modulů v Nixu. Aby se daly některé moduly použít na více místech, vytvořili jsme repozitář nixos-modules. Zatím obsahuje modul na použití libvirtu, který funguje i ve VPS.

build.vpsfree.cz

Máme nový (resp. je to nějaký starší HW) stroj na sestavování OS a bootovacích obrazů pro nody. I zde je vpsAdminOS, ale nainstalovaný na disku a bootuje ze ZFS. I takto se dá použít.

Chystám se zde taky automatizovat build šablon distribucí pro VPS. Nyní se šablony musí sestavovat a testovat manuálně, což se nikomu nechce dělat a zejména rolling-release distribuce zaostávají. O tom zase někdy příště.

IPv6 na stagingu

Kdo máte VPS na stagingu, určitě jste si všimli problémů s IPv6. Bylo to tím, že neseděly BGP timeouty mezi Dell switchi a birdem na node1.stg. Už nějakou dobu to funguje stabilně.

Co dál

Ke spuštění produkčního node chybí: NFS (viz výše) a syslog namespace. Monitoring už tak nějak funguje — při výpadku nám chodí SMS, ale ještě je co vylepšovat co se týče sledování zdrojů.

syslog namespace je důležitý k tomu, abyste dostávali informaci o tom, že vaši VPS navštívil OOM killer. Teď vám mohou mizet procesy a nevíte o tom. Patchset už máme, musí se to přidat do kernelu a vyzkoušet.

Včera jsem v Arcade hry narazil na herní automat s hrou podle animáku Raubíř Ralf. Tento film vznikl na motivu neexistující hry, autoři

Příspěvek Hra Raubíř Ralf pochází z Spajk.cz

Stručné shrnutí, které si sem odložím…

Tady to začalo.

Tady jsem se inspiroval.

Tady jsem se rozhodl.

Tady jsem si ujasnil.

A na tohle si rád občas vzpomenu.

---

Hradla, volty, jednočipy jsou na trhu rok a půl. Splnily tak půlku toho seznamu.

Dva týdny jsou venku Porty, bajty, osmibity. Tam jsem sepsal asi tak čtvrtinu věcí, co zbývaly.

Jsem zhruba ve dvou třetinách psaní třetího pokračování Čipy, data, procesory. Snažím se dopsat zbytek z toho seznamu. VHDL, FPGA, vlastní procesory, … Osud pokračování je plně v rukou čtenářů. Když o text nebude zájem, nechám rukopis ležet a budu dělat něco jiného…

Toto je můj Opus Magnum, mé „Velké dílo“. Dávám to do uvozovek a kurzivou, aby bylo jasno, že jde o hyperbolické vyjádření.

Ještě k tomu přibudou dva menší tituly, víceméně na vaše přání. V jednom se bude pokusničit s rádiem, v tom druhém se budou bastlit gadgety. To, jestli vzniknou, asi nechám taky na čtenářích.

Pokud vše dobře půjde, v roce 2022 bude hotovo…

Včera vyšel pátý megawad pro hru Doom (1993) od Johna Romera. SIGIL.

Stejně jako předchozí dvě mapy od mistra, tedy Tech Gone Bad (E1M8) a Phobos Mission Control (E1M4) je i SIGIL ke stažení zcela zdarma. Jediné co potřebujete je nějaký source port (nejlépe gzdoom) a také wad z původní hry (tj původní Doom z roku 1993 nebo Ultimate Doom z 1995). K sehnání za pár korun na Steamu.

Hra loni oslavila 25 výročí a přitom má stále co nabídnout. Je neuvěřitelné, co se dá s původním engine (všechny nové Romerovi mapy ale vyžadují engine, který překonává limity původního DOS engine, ale to vlastně na věci nic nemění, engine a vzhled zůstává stále původní, akorát je umožněno tam mít více objektů) a s původníma texturama vytvořit za krásu. Srovnal bych to třeba s megawadem Chillax, což je ale úplně jiné téma.

Už první mapa obsahuje prvky, které si Romero oblíbil v E1M4 a zejména potom E1M8. Nechci prozrazovat příliš, fakt si to zahrajte.

U třetí mapy jsem měl přímo mrazení v zádech. Malá mapa, velké detaily. Využití prostoru a momentu úžasu.

Co mě potěšilo je obtížnost. Po neuvěřitelně obtížné episodě Thy Flesh Consumed (hlavně Perfect Hatred, taky od Romera, což je hned na počátku episody pořádný nášup) jsem od ohlášení SIGILu čekal další nárůst obtížnosti. Naštěstí se tak nestalo. Sigil není problém hrát na Ultra-Violence (což je vlastně jediná obtížnost, na kterou se Doom obecně hraje) a i při prvním průběhu hry to není žádný problém. Obtížnost se příjemně rozvíjí s dalšími mapami. Nábojů je (jak už to v pekle bývá) málo, je potřeba s nimi umět hospodařit. Snad jedinou výtku bych k episodě měl, je tam poměrně málo možností pro infight potvor mezi sebou (což je obvykle výsada map, které municí šetří). Tady si musíte poradit sami.

Za mě jednoznačně palec nahoru, je skvělé, že i pro 25 let starou hru vycházejí mapy nejen od fanoušků, ale i od původního autora. A to ještě navíc zdarma, pokud nechcete sběratelskou edici s grafikami nebo trička.

Tak se do toho pusťte a ať vám nikdo nestojí v cestě. Ale s Borcem v koridoru si hravě poradíme, tak jak kdykoliv před tím. ;-)

Minulý rok v srpnu jsem psal o tom, že jsem si na domácí notebook nainstaloval Fedora Silverblue. Tenkrát to byla hodně čerstvá zkušenost. Samotné Silverblue se za tu dobu taky hodně posunulo. Jak se tedy mi funguje na neměnném systému s odstupem roku?

Když jsem minulý rok Silverblue nainstaloval, hned jsem přešel na Rawhide, který jsem měl na notebooku i před tím. Mít možnost vrátit se ke stavu před aktualizací se u Rawhidu, kde se občas něco rozbije, opravdu hodí. Nicméně musí vám spolehlivě fungovat aspoň OSTree, což minulý rok v Rawhidu tak pravidlem nebylo. Od určitého snapshotu jsem nebyl schopný aktualizovat, takže jsem si musel držet poslední snapshot, kde to fungovalo, a do něj vždycky nabootovat, stáhnout poslední verzi systému a do ní rebootovat. To mě pomalu přestávalo bavit a když jsem se tomu snažil přijít na kloub, smazal jsem si omylem ten poslední snapshot s fungujícími aktualizacemi a ocitl se v pasti. To mě konečně donutilo k reinstalaci.

V poslední době nemám doma moc čas experimentovat a notebook prostě jenom používám, takže jsem se vrátil ke stabilní Fedoře. Od té doby prostě funguje.

Co je na Silverblue naprosto skvělé, jsou aktualizace. rpm-ostree vám na pozadí stáhne novou verzi a GNOME Software vám jenom oznámí, že máte k dispozici aktualizovanou verzi systému a měli byste rebootovat. Ne, že by aktualizace v „balíčkových“ systémech byly složité, ale vyžaduje to nějakou akci uživatele. Většina BFU, kterým jsem Fedoru nainstaloval, neaktualizuje, i když jim to GNOME Software připomíná. A já nemám odvahu jim to pouštět automaticky, protože to prostě není bezpečné. Musím to tak dělat ručně, když se k jejich počítači dostanu, což je klidně jenom jednou za několik měsíců.

Ještě jednodušší jsou aktualizace aplikací. Silverblue se u nich dost blíží tomu, co známe z Androidu. Všechny aplikace mám ve Flatpaku, aktualizují se zcela nezávisle na systému a pokud si nastavíte automatické aktualizace, tak vám GNOME Software hlídá nové verze, stahuje je a na pozadí rovnou aplikuje. Na rozdíl od balíčků nejsou běžící aplikace nijak dotčeny, protože jim Flatpak nemění za běhu soubory. Aplikaci stačí zavřít a znovu otevřít a máte novou verzi.

Upgrade systému v případě Silverblue vlastně není nic jiného než aktualizace. Technicky je rozdíl v tom, že se přepnete do jiné větve repozitáře OSTree, a ne, že jen poskočíte o jeden commit ve stávající větvi, ale ve výsledku to je jenom stažení dalšího snapshotu a nabootování do něj. Jediný čas, který vám to vezme, je reboot počítače. A když vám nová verze systému z nějakého důvodu nevyhovuje, můžete se dalším rebootem vrátit k předchozí.

Jedním z velkých problémů Silverblue v minulém roce bylo pomalé stahování aktualizací z OSTree serveru. Nebyl totiž nijak zrcadlený a jak rostla popularita Silverblue, rychlosti padaly dolů až třeba na 10-15 kbps. Ne, že by to až tak vadilo. Pokud člověk spoléhal na automatické stahování, nemusel to moct řešit, protože se to stahovalo na pozadí a bylo vcelku jedno, jestli to trvalo 10 minut nebo 5 hodin. Pokud ale člověk chtěl z nějakého důvodu aktualizovat hned, bylo to dost otravné. Dnes už takový problém Silverblue nemá. Fedora Project zapracoval na lepší konektivitě a rychlosti jsou dnes v jiných řádech.

Co se týče aplikační výbavy, tak téměř výhradně závisím na Flathubu, kde je dnes skoro 600 aplikací a popravdě si nemůžu vzpomenout, že by mi něco chybělo. Trochu mi chybí stabilní Firefox, na jehož flatpaku Mozilla pořád pracuje, a já tak musím pořád používat Firefox DE z našeho testovacího repa. I takový Steam ve Flatpaku mi funguje výborně a díky Protonu si zahraju i řadu her původně pro Windows.

Pomalu ale jistě se rozjíždí i flatpak repozitář Fedory. Momentálně se v něm nachází cca 25 aplikací. Jeho výhodou je, že bude v budoucnu v Silverblue přednastavený a že v něm člověk dostane stejné záruky jako u repozitářů s balíčky Fedory, protože flatpaky v něm jsou skládané z balíčků ve Fedoře.

Jediná věc, u které jsem v Silverblue zatím tvrdě narazil, je podpora domácí tiskárny od HP, která vyžaduje stažení proprietárního firmwaru. Ten se stahuje do cesty, která není v Silverblue zapisovatelná, a tudíž to selže. Mysleli jsme si, že to vyřešíme patchem v hplip, ale způsob, jakým to hplip dělá, je dost zvláštní. Stáhuje totiž binární blob ze serverů HP a až ten dělá samotné stahování.

Další věcí, která ještě nefunguje tak optimálně, jak bych si představoval, je Toolbox, což je nástroj nad Podmanem, který vám vytvoří kontejner, v kterém máte standardní Fedoru s balíčky. Připojí vám to tam automaticky /home z hosta, připojí se to k zobrazovacímu serveru, takže si tam můžete instalovat i desktopové aplikace, které třeba nejsou pro Flatpak. Problém je, že Podman se pořád dost mění, což rozbíjí kompatibilitu s Toolboxem. S tímto budeme ještě muset něco udělat, aby to bylo připravené na prime time. Zatím se jedná pouze o sadu shell skriptů, které parsují konzolový výstup Podmanu. Plánuje se přepsání do Go a používání API Podmanu. Testy s Toolboxem by také měly přibýt do CI Podmanu.

Jinak ale musím po roce používání konstatovat, že Silverblue je zatím to nejvíc „just works“ distro, jaké jsem zkoušel. Upgrady jsou extrémně snadné a rychlé, aktualizace fungují téměř kompletně automaticky, aplikace si žijí svým životem a nejsou ovlivněné změnami v systému atd.

Chtěli bychom časem nahradit tradiční Fedora Workstation právě Silverblue na pozici výchozí desktopové varianty Fedory, ale já zvažuju, že to budu instalovat na počítače BFU kolem mě už nyní.

Odpočinek je zásadní pro regeneraci a růst, což umožňuje později podávat dobré výkony. Proto pravidelně pořádám Relaxační a růstový pobyt v Huttendorfu...

Pokračujeme v příběhu [1] [2] o pomalém ZFS na FreeBSD. Tentokrát se podíváme na to, co jsou to malé soubory z hlediska rychlosti čtení ZFS.

Hlavní dva parametry rotačního disku, které ovlivňují rychlost čtení z disku, jsou:

• Rychlost otáčení (rpm) určující kolik bloků za sekundu je disk schopen přečíst. Během čtení náhodně umístěných bloků je disk schopen přečíst jeden blok (4kiB) za jednu otáčku disku. Tedy pro 7200rpm disk platí, že rychlost čtení náhodných bloků je 7200 / 60 = 120 * 4kiB = 480 kiB. Toto je tedy nejnižší rychlost čtení, které je disk schopen dosáhnout.
• Sekvenční rychlost, ta je určena především hustotou záznamu dat na disku a obvodovou rychlostí disku. Dnešní disky mohou číst rychlostí začínající na 200MB/s, ale pozor, čím více ke středu disku, tím rychlost klesá a může klesnout až někam k 60MB/s podle typu disku.

Je tedy jasné, že čím menší soubory čteme, tím nižší bude rychlost čtení. Ale jak nízká? Pro opravdu malé soubory (např. maildir) nelze očekávat více než 480kiB/s a to ještě za předpokladu, že jsou dopředu načtené inode (informace o umístění bloků na disku). Pokud nejsou a pro každý čtený soubor je potřeba ještě přečíst jeho inode, tak efektivní rychlost může klesnout na polovinu, tedy někam k 200kiB/s. S tímto se skutečně mnoho dělat nedá. Některé FS problematiku malých (ale opravdu malých na úrovni desítek B), řeší tak, že je umísťují přímo do adresářového záznamu, data souborů se tedy dostanou do cache už při načtení adresáře a další výlety na disk nejsou potřeba.

U souborů o velikosti 1MiB lze teoretickou očekávanou rychlost čtení vypočítat. Víme, že disk umí 200MiB/s, 1MiB se čte 5ms. Seek (otáčka disku) mezi soubory je 8.3ms. Na jeden 1MiB soubor je tedy potřeba 13ms. To je 75 souborů za 1s. Tedy 75MiB/s. Připustíme-li, že pro každý soubor je potřeba ještě jeden extra výlet do inode, vyjde nám teoretická rychlost 46 souborů / s (46 MiB/s).

Jaká je praxe? Napsal jsem si jednoduchý skript, který rozdělí soubory v datasetu podle jejich velikosti (jedná se o reálné soubory, proto nebylo možné filtrovat na přesnou velikost 1MB, 2MB apod. takže se jedná o skupiny souborů o velikosti vždy v nějakém rozmezí) a tyto soubory jsem z disku četl. V grafu je uvedena průměrná rychlost čtení souborů v daných skupinách.

První dataset je stejný, jaký jsem používal u testů v minulých článcích a obsahuje spíše malé soubory o velikosti do 20MB maximálně.

Rychlost čtení těch nejmenších souborů je bez překvapení, ale rychlost čtení skupiny kolem 1MB je 11 – 16MB/s. Tedy 3x až 7x pomaleji, než nám dal teoretický výpočet. Připomínám, že se jedná o zpool se třemi mirrory, tedy celkem 6 disků. Zpool by se měl chovat jako RAID10, ale v takovém případě bychom mohli očekávat zcela jiný výkon, který se nám ovšem nedostává. K očekávaným rychlostem kolem 70MB/s se dostáváme až u souborů o velikosti cca 5MB. Ani čtení souborů o velikostech nad 10MB nedosahuje nijak slavných rychlostí. Stále jsme na 25% výkonu tohoto zpoolu.

Druhý dataset obsahuje soubory o velikostech typicky desítky MB. Do grafu jsem záměrně umístil i předchozí výsledky, tento větší dataset tedy začíná od skupiny 10-20MB:

Jak vidíme, nějaké saturace rychlosti se dosahuje až někde kolem velikostí souborů 50 MiB. Vše menší se dá z hlediska tohoto ZFS považovat za malé soubory, protože nedosahuje ani teoretických rychlostí ani saturace. I při tomto testu se vytížení disků (iostat -x) pohybuje kolem 30-40%. Skutečně velké soubory tento zpool umí číst a za zapisovat rychlostmi kolem 400MB/s.

Čím to je fakt netuším. Jak jsem psal minule, systém se chová OK a velmi plynule a celé to na mě dělá dojem, že je tam někde skutečně „sleep“ na několik ms jako obrana proti zahlcení IO. Na druhou stranu tyto výsledky poskytují návod, jak k tomu FS přistupovat. Pro program je ideální data ukládat agregovaná do větších celků o velikostech cca 100MB. Například pro archiv emailů se hodí dovecot formát mdbox, který ukládá zprávy do souborech o velikosti max 10MB. Na komprimovaném datasetu tak lze dosáhnout skutečně efektivního uložení archivu emailů (stovky tisíc zpráv v několika málo rozumně velkých souborech o celkové velikosti pár GB, místo stovek tisíc jednotlivých maildir souborů).

Výkonná rada SPIR jen s minimálními obměnami tereza.tumova@… Čt, 05/23/2019 - 20:00

Pro bezpečnost našich členů zavádíme dvoufaktorovou autentizaci do vpsAdmin pomocí TOTP.

Ve vpsAdminu si nyní můžete nastavit dvoufaktorovu autentizaci (2FA) pomocí TOTP. Pro autentizaci můžete používat např. mobil s aplikací Google Authenticator, FreeOTP, nebo libovolný program implementující TOTP. Pro nastavení stačí do aplikace naskenovat QR kód, popř. opsat tajný klíč. Aplikace je pak kdykoli schopna zobrazit aktuální heslo pro přihlášení, které se mění každých 30 sekund.

Do vpsAdminu si takto můžete přidat více autentizačních zařízení a k přihlášení půjde využít kterékoli z nich, co máte zrovna po ruce. Dvoufaktorová autentizace je vynucena máte-li nastaveno a povoleno alespoň jedno zařízení. Bez tohoto zařízení se do vpsAdminu nepřihlásíte: ani do webového rozhraní, ani u API.

Pokud náhodou o svoje autentizační zařízení přijdete, můžete použít obnovovací kód, který vám vpsAdmin při nastavení zařízení jednorázově zobrazí.

Postup nastavení i se screenshoty je popsán v KB.

Zavedení 2FA si vyžádalo zpětně nekompatibilní změnu v protokolu HaveAPI, takže pokud používáte vpsfreectl nebo jinou knihovnu pro přístup k API, musíte aktualizovat.

Staráte se o web na WordPressu a nejste si jistí, jestli děláte všechno, co je potřeba a jestli to děláte správně? Nebaví vás hledat řešení opakujících se nebo nových chyb a testování pluginů vás vyloženě unavuje? Přijďte na mé školení, kde se dozvíte, jak se to má dělat správně a naberete hromadu tipů. S WordPressem ...

Přečíst celý článek > Školení WordPressu