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í.

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

Dne 13.4.2019 se v Bratislavě v prostorách vysoké školy FIIT STU konala konference OpenCamp. Jednalo se o druhý ročník této konference, která je zaměřená na otevřené technologie. Takovéto konference jako jsou OpenAlt nebo Linux Days jsou ideální nezávislý zdroj informací pro každého studenta, nadšence a nebo profesionála a proto můžu návštěvu takových konferencí jen doporučit. Konference byla velice dobrá...

Měl jsem tu rozepsáno pár komentářů, ale ty diskuse se mezitím odsunuly kamsi do historie, takže to raději hodím sem do blogu.

Pokud jste se také dostali do situace, kdy potřebujete z PowerPointové prezentace vytisknout jen poznámky, na tento návod jste narazili dobře.

Příspěvek Jak vytisknout poznámky z PowerPointu pochází z Spajk.cz

Doporučení SPIR pro vydavatele: příprava uživatelského rozhraní žádosti o souhlas se zpracováním osobních údajů z online identifikátorů tereza.tumova@… Út, 05/14/2019 - 09:02

Doporučení SPIR k implementaci GDPR: reakce na žádosti uživatelů internetu o poskytnutí informací o tom, jaké osobní údaje jsou o uživateli zpracovávány tereza.tumova@… Út, 05/14/2019 - 08:27

Když Dan Tentler uviděl na Instagramu reklamu, která tvrdí, že si máte hacknout svojí ranní rutinu tím, že budete pít proteinové smoothie od Nescafé, tak celkem oprávněně zaglosoval, že pití kafe nebo smoothie není hackování a už vůbec se nedá nazvat hackováním pouhá změna vaší ranní drogy. Zároveň ho napadlo se podívat, kolik lidí používá nescafe jako heslo a zjistil, že docela dost.

No jo, ale co je to dost? A jak jsou na tom ostatní značky kafe? A který kafe je nejlepší podle toho, jak moc se používá jako heslo? Čas na silly password research 🙃

Jak moc to které heslo bylo v nějakém známém úniku dat se dá zjistit z Pwned Passwords, dotazy se dají posílat strojově na API a seznam značek kafe je třeba na Wikipedii. Takže tady je…

Top 10 značek kávy

1. georgia (57531× použito jako heslo)
2. jacobs (33594×)
3. starbucks (17286×)
4. franck (14508×)
5. nescafe (7708×)
6. justus (7484×)
7. timhortons (1436×)
8. lavazza (1388×)
9. highpoint (1304×)
10. folgers (1288×)

Jo, asi všechno z toho je taky něco jinýho než kafe. Teda snad kromě Jihlavanky – jihlavanka, česká značka kávy, která s Jihlavou a Českem už nemá nic společného, byla jako heslo použita 63×. Georgia je stát v USA, stát na rozhraní Evropy a Asie (česky Gruzie), font, lodě, ponorka a dokonce asteroid (i jeho název někdo použil, v heslu georgia359). Georgia je i jméno, podobně jako Franck nebo Justus. Jestli lidi mají v heslu kafe nebo ponorku, to už se asi nedozvíme.

Ale jen jeden hardcore fanda používá jako heslo jitteryjoes. Jittery Joe's je nějaký kafe z Atén, což je nějaký město v Georgii. V tý Georgii v USA. O ziferblat, deathwishcoffee („Vaše poslední přání?“ – „Kafe! Ne, ne, počkat, raději si změním heslo“) nebo keurigdrpepper nikdo nezavadil ani speciálním znakem.

Službu Have I Been Pwned provozuje Troy Hunt a jeho jméno a příjmení použilo jako heslo 11 lidí, kteří se asi jen jmenují stejně. Moje jméno a příjmení sice nikdo jako heslo zatím nepoužil, ale mspacek bylo v databázi 9× a spacekm použili dva uživatelé. Chci ty lidi potkat. Ačkoliv prý jeden z nich má v e-mailu slovo „murder“, tak možná bude stačit, když mi jen napíšou.

Seznam všech kafehesel i jednoduchý skript na GitHubu. A jak teda vlastně vypadá to hackování? Třeba takhle nebo takhle.

Před týdnem jsem tu psal, jak bych chtěl něco dělat se suchem a dostal jsem spoustu souhlasných reakcí. Vydaly by na obrovský projekt, ale abychom nezůstali jen u řečí, chtěl jsem co nejdříve vykopnout nějakou ultra základní verzi, kterou můžeme dál rozšiřovat.

Dnes vám proto představuji vám první verzi suchobijci.cz

Jelikož jsem nedávno opustil služby Googlu, bylo potřeba mimo jiné přenést kontakty, které jsem tam měl za ta léta nastřádané

Příspěvek Jak přenést kontakty z Google na iCloud pochází z Spajk.cz

V poslední době jsou populární zcela bezdrátová sluchátka. Rozhodl jsem se, že si taky jedny pořídím na poslouchání hudby „on the go“. Nakonec jsem se rozhodl pro Samsung Galaxy Buds. Proč jsem si vybral zrovna je a jaké s nimi mám první zkušenosti?

Stejně jako drátová, tak i ta zcela bezdrátová se dělí na dva základní druhy:

• pecky – pohodlnější na nasazení, otevřené (neucpávají zvukovod), omezená kvalita zvuku (při nejlepší snaze z pecek výborný zvuk nedostanete),
• špunty – hůře se nasazují, zasunují se do zvukovodu, čímž blokují okolní zvuky a nevyžadují takovou hlasitost, nemají taková omezení, co se kvality zvuku týče, a dokáží vyprodukovat výborný zvuk.

Myslím, že to je především o osobní preferenci. Mně přijdou pecky o cosi přirozenější na nošení, ale špunty mi vyloženě nevadí. U zcela bezdrátových sluchátek ale nasazení do ucha do značné míry determinuje také celkový design. Pecky vám totiž v uchu do značné míry drží tak, že sedí na jeho spodní části. Pokud není kabel, musí mít zátěž v podobě něčeho jiného. Proto se pecková zcela bezdrátová sluchátka dělají ve tvaru „stopky“. Typicky jsou to Apple AirPods nebo jejich napodobeniny Huawei FreePods 2.

Mně se tento design nelíbí. Od zcela bezdrátových sluchátek vyžaduji maximální nenápadnost, což několik centimetrů trčící bílé stopky prostě nesplňují. Proto jsem se hned na začátku rozhodl hledat mezi špunty, protože v této kategorii se téměř všechny modely usazují celé do ucha a jsou výrazně méně nápadné. Druhým důvodem, proč jsem se rozhodl pro špunty, je obecně výrazně lepší kvalita zvuku. Tím, že ucpou zvukovod a reproduktor dostanou přímo do něj, získávají nad peckami takovou výhodu, že už je pro sebelepší pecky těžké ji překonat.

Každý to ale může mít jinak. Na poslouchání na ulici nebo v tramvaji asi bude většině lidí kvalita zvuku z pecek stačit a zase mají výhodu v tom, že jsou otevřená a přirozeně pouští dovnitř zvuk z okolí, což se v městském provozu taky hodí. Jak dozvíte dále v textu, některá špuntová sluchátka se snaží dosahovat stejného efektu různými vychytávkami.

Mezi špuntovými sluchátky je v kategorii zcela bezdrátových už nyní velmi slušná nabídka přibývají další. Nejdříve mě zaujala sluchátka Sony WF-1000X. Od Sony už mám velká bluetooth sluchátka, s kterými jsem hodně spokojený, a Sony je dlouhodobě špička mezi hudební elektronikou. I tato sluchátka mají velmi dobré recenze. Minulý rok dokonce některá srovnání vyhrála. Hlavně díky výbornému zvuku, pohodlnosti a také díky funkci aktivního potlačení okolního zvuku, čímž jsou v této kategorii ojedinělá. Nicméně mají i svá negativa: ke zdrojovému zařízení nejsou připojená obě sluchátka, ale jenom to hlavní a druhé se připojuje k hlavnímu. Podle recenzí byl občas v komunikaci mezi sluchátky problém. Navíc toto uspořádání má větší latenci, což se projevuje např. jako zpoždění zvuku u přehrávání videa. Sluchátka jsou taky na trhu už rok a půl, což je v takto dynamicky se rozvíjejícím segmentu dlouho. Výsledkem toho například je, že místo Bluetooth 5 podporují jenom 4.1.

Výborný zvuk a funkce nabízejí Sennheiser Momentum, které se ale pohybují už na cenovce 8 tisíc, což je výrazně víc, než jsem do takových sluchátek ochotný investovat. Výborné hodnocení má také sluchátka Jabra Elite 65t, ale cenovka už je také poněkud vyšší.

Nakonec jsem došel k závěru, že mým požadavkům a očekáváním nejvíc vyhovuje novinka na trhu – Samsung Galaxy Buds. I cenově vycházejí lépe než všichni výše zmínění konkurenti.

Galaxy Buds mají příjemně malou zaoblenou krabičku, která se v pohodě ztratí v kapse od kalhot, takže je můžete mít pořád u sebe. Byl jsem příjemně překvapený, jak malá ve skutečnosti je. Malá jsou i samotná sluchátka. Mají necelých 6 g. Hrát prý podle Samsungu vydrží 6 hodin (z krabičky by pak měly jít nabít ještě zhruba 2x). To jsem neměl možnost otestovat, protože jsem je nikdy tak dlouho nepoužíval a vždy je vrátil do krabičky, kde se zase dobila. Krabička umožňuje jak nabíjení po drátě (USB-C), tak bezdrátově. U nejnovějšího Samsung S10 můžete krabičku nabíjet přímo na zádech mobilu. Já mám bezdrátovou nabíječku od Samsungu a funguje to stejně dobře.

Fungování s Androidem je naprosto bez problémů. Jdou spárovat jako jakékoliv jiné Bluetooth zařízení. Abyste ale měli přístup k dalším funkcím a nastavením, musíte si nainstalovat aplikace Galaxy Wearable. Tu už používám pro hodinky Gear S3, takže jsem musel doinstalovat jenom plugin. Jak si sluchátka v aplikaci jednou nastavíte, stačí je jen vytáhnout z krabičky, zastrčit do uší a poslouchat. K mobilu už se připojují automaticky.

Zvukově mi na tento „form factor“ přijdou velmi dobrá. Neměl jsem možnost porovnávat třeba se zmíněnými Sennheiser Momentum, ale se zvukovým výstupem jsem spokojený. Na krabičce najdete nápis „Sound by AKG“, což popravdě nevím, co si pod tím představit. AKG byla rakouská firma zaměřující se na kvalitní audio techniku. Sám od nich mám velká drátová sluchátka AKG K 550. Ta byla už v roce 1994 koupená americkou společností Harman, která byla v roce 2016 pro změnu koupená Samsungem. Tyhle akvizice ještě nemusí znamenat přerušení kontinuity vývoje a produktových řad, ale po akvizici byla rakouská dceřinka rozprášena a značka převedená přímo pod Harman. Hlavní inženýři AKG podle všeho utekli a založili společnost Austrian Audio. Doufejme ale, že nějaký odkaz a know-how AKG v Samsungu zůstaly zachovány.

Kvalita zvuku přes Bluetooth je do značné míry determinována použitým kodekem. Galaxy Buds podporují Scalable Codec, SBC a AAC. Scalable Codec je proprietární kodek od Samsungu, o kterém kromě marketingových proklamací, jak je úžasný, nic bližšího nevíme. Navíc ho podporují jen zařízení od Samsungu. SBC je nativní kodek Bluetooth, který dokáže poskytovat rozumnou kvalitu, pokud má dostatečný bitrate (zvládá až 500+ kbps). Bohužel většina zařízení ho používá v podstatně nižších bitratech a kvalita tomu odpovídá. V Androidu (a i iPhonu) se vám ale u Galaxy Buds automaticky zapne AAC (pravděpodobně s bitratem 264 kbps), což není nic srovnatelného s LDACem na 990 kbps, ale pro sluchátka takových rozměrů adekvátní. Zvláště, pokud posloucháte hlavně Spotify, který vám nabídne maximálně OGG na 320 kbps. Hodně recenzí oplakává chybějící AptX, ale je to nonsense. Není to totiž žádný úžasný kodek a ani při maximálním podporovaném bitratu vám neposkytne lepší kvalitu zvukového výstupu než AAC.

Galaxy Buds podporují Bluetooth 5. To má dvakrát větší propustnost (2 Mbps), což ale u sluchátek, která podporují jen AAC 264 kbps, stejně nevyužijete. Má ale taky teoreticky až čtyřnásobný dosah oproti Bluetooth 4.2, což už užitečné je. Můžete nechat mobil ležet v obýváku a pohybovat se různě po domě, aniž by vám vypadlo spojení. Můj mobil umí Bluetooth 5 taky a musím říct, že delší dosah je znát. Nedělal jsem nějaký „stress test“, jak daleko Galaxy Buds ještě vydrží připojené, ale třeba v posilovně jsem nechal mobil na baru a pohyboval se v rádiusu 15 metrů s překážkami, aniž by došlo k sebemenšímu výpadku spojení. Moje velká Bluetooth sluchátka Sony h.ear on 2 Mini podporují pouze Bluetooth 4.1 a začínají se zaškobrtávat už při vzdálenosti 8-10 metrů.

Se špunty jsem měl vždycky problém, že mi špatně držely v uchu. U Galaxy Buds moje obavy rozptýlily už přečtené recenze a v praxi se mi to jenom potvrdilo: drží v uších výborně. Nespoléhají se na držení ve zvukovodu, ale díky malým „křidélkům“ se zachytí za ohyb ucha a drží, ať děláte sebedivočejší pohyby. Drží, i když je nezastrčíte pořádně do zvukovodu a máte je „na volno“, což může vyhovovat těm, kteří preferují volnější styl pecek. Přijdete tak ale ten plný zvuk, který se dostaví, když špunty kompletně vyplní zvukovod.

Na to, co všechno obsahují a jak dlouho vydrží, jsou Galaxy Buds obdivuhodně malá zařízení. Když si je dáte do uší, tak sice nejsou zcela neviditelné, ale v rámci možností docela nenápadné. V tomto mě nijak nezklamala. V kombinaci s chytrými hodinkami, které pojmou až 2 GB hudby v podobě lokálních skladeb nebo offline režimu Spotify, je to opravdu lehká kombinace na běhání.

Sluchátka umí taky hromadu chytrých věcí navíc. Obě mají dotykové plošky, kterými můžete provádět různé příkazy: klepnutí – zastavit přehrávání, poklepání – skok na další skladbu, trojité klepnutí – skok na předchozí skladbu. Tyto akce jsou fixně dané. Můžete si ale nastavit akce pro gesto „klepnout a držet“. Na pravém sluchátku mám pod tímto gestem ztlumení hudby a puštění okolního zvuku do sluchátek, abych rozuměl, když na mě někdo mluví. Na druhém mám potom Google Assistenta. Stačí říct „Přehraj Iron Maiden ve Spotify“ a ani nemusíte tahat mobil s kapsy.

Aplikace v mobilu pak dovoluje nastavit i další věci. Např. ekvalizér. Můžete si taky trvale zapnout okolní zvuk. Jelikož máte zvukovod ucpaný sluchátky, slyšíte okolní zvuky velmi omezeně. Galaxy Buds jej ale můžou odchytávat mikrofony a pouštět do sluchátek. Můžete to vyvolat nárazově gestem nebo to zapnout trvale v aplikaci, když třeba jdete běhat. Sluchátka vám potom mixují puštěnou hudbu se zvuky z okolí, aby vás třeba nesrazilo auto. Intenzita se dá nastavit, zapnout lze důraz na lidský hlas. Můžete si nastavit také čtení oznámení z telefonu, což já mám vypnuté, protože je už dostávám do hodinek.

Třešínkou na dortu je potom skóre opravitelnosti 6/10 od Fixit, což považuji u tak malého zařízení za velmi dobré. Pro porovnání Apple AirPods mají 0/10 a podle Fixit jsou tak zcela neopravitelné. V době, kdy se opravy na místo neustálého kupování nových věcí opět dostávají do módy, je to taky podstatná vlastnost.

Máme vlastní modul pro Terraform, který umí vytvářet a upravovat VPS na naší infrastruktuře, nahrávat veřejné SSH klíče a spouštět příkazy přes SSH.

Terraform je nástroj pro správu infrastruktury pomocí konfiguračních souborů. Podporuje spoustu různých poskytovatelů hostingu, cloudů a podobných služeb. Nyní je možné pomocí něj konfigurovat i naše VPS.

Náš plugin pro Terraform aktuálně umí vytvářet a upravovat VPS, nahrávat veřejné SSH klíče a spouštět příkazy přes SSH. Plugin, pokyny k instalaci a ukázku použití najdete na GitHubu.

Případné chyby prosím hlaste u repozitáře. Samozřejmě se můžete také zapojit do vývoje, chtělo by to ještě dodělat podporu pro správu datasetů, mountů a určitě se toho najde více.

Terraform pluginy se nejsnadněji píšou v Golangu, takže jsme v Golangu potřebovali taky klienta k našemu API. Díky tomu, že se naše API umí samo pěkně zdokumentovat, klient pro Golang je kompletně automaticky vygenerovaný. Výsledkem je tedy generátor klientských Golang knihoven pro HaveAPI a samotný klient k našemu API, který je možné použít nezávisle na Terraformu.

GDPR Transparency & Consent Framework od IAB Europe ve verzi 2.0 k připomínkování tereza.tumova@… Po, 04/29/2019 - 20:33