Planeta.OpenAlt.org

Pomalé ZFS – zkuste to paralelně, milý admine

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.


Pozvánka na 165. sraz příznivců svobodného přístupu – Brno + beachvolleyball

červen
14
Openalt.org

Spolek OpenAlt zve příznivce svobodného přístupu na sraz, který proběhne v pátek 21. června od 18:00 hodin ve Sport Centru Srbská (Srbská 4). Od 19:00 je pro zájemce zamluveno hřiště na plážový volejbal.

 

Jak chránit soukromí dětí na internetu

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

Jak zabránit počítači aby se uspal nebo zamknul

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

Revize šablon distribucí: na stagingu nově openSUSE, Slackware a Void Linux

červen
11
vpsFree.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.

Pozvánka na 165. sraz OpenAlt – Praha

červen
10
Openalt.org

Červnový pražský sraz spolku OpenAlt zahájí Jaroslav Tulach z Oracle Labs přednáškou na téma Úvod do GraalVM – nejrychlejšího virtuálního stroje na světě. Následovat bude neformální setkání a diskuse na téma GraalVM.

Sraz se koná ve čtvrtek 20. června od 18:00 v Praze – místo ještě upřesníme. Akce je volně přístupná (i Go nebo Rust programátorům), ale z kapacitních důvodů prosíme, abyste nám dali vědět, že přijdete – e-mailem na graalvm-2019-06-20@openalt.org nebo zde na webu. (není to povinné, ale pokud by se nás sešlo moc, přednost budou mít ti, kteří se přihlásili včas)

GraalVM – logo

Výkonná rada SPIR opět potvrdila Michala Hanáka na postu předsedy

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

Praha, 7. června 2019 – Výkonná rada Sdružení pro internetový rozvoj (SPIR) zvolená na květnové valné hromadě opět potvrdila Michala Hanáka ze společnosti Mafra na postu předsedy. Místopředsedy se stali Martin Šebesta ze společnosti OMD Czech a Michal Feix za Seznam.cz.

V novém funkčním období se chce předsednictvo soustředit na intenzivnější komunikaci se všemi členy sdružení, protože s přibývající agendou, nejen v oblasti Public Affairs, je třeba hledat širokou shodu. Bude také pokračovat v již tradičních projektech jako je NetMonitor, který musí lépe reflektovat proměnu online trhu a hlavně chystané změny legislativy. „SPIR původně vznikl z potřeby kultivovat rychle se rozvíjející digitální prostředí a podílel se na definování jeho standardů. I po téměř dvaceti letech se trh stále dynamicky vyvíjí a role SPIR se v tomto směru nemění,“ řekl staronový předseda Michal Hanák.

Valná hromada SPIR se sešla na konci května, aby schválila činnost sdružení za uplynulý rok a stanovila si oblasti, kterým se v dalším období bude věnovat. Do výkonné rady bylo zvoleno 13 z původních 15 členů: Marek Antoš (Internet Info), Petr Bednář (AdActive), Karel Brýna (Tiscali Media), Tomáš Búřil (Dentsu Aegis Network Czech Republic), Michal Feix (Seznam.cz), Daniel Grunt (FTV Prima), Michal Hanák (MAFRA), Jaroslav Kábele (ČTK), Martin Kyncl (TV Nova), Martin Picek (Mindshare), Martin Šebesta (OMD Czech), Libuše Šmuclerová (Czech News Center), Michael Štádler (Adform). Nově společnost Economia ve výkonné radě zastupuje Štěpán Burda, který nahradil Romana Latuskeho, a novým členem výkonné rady se stal Jan Bambas z Universal McCann. 

Java a unixové doménové sokety, FD, systemd a xinetd

červen
05
Franta Kučera

Internet běží sice převážně na TCP/IP, ale v rámci jednoho počítače máme i vhodnější způsoby komunikace. V tomto článku se podíváme na unixové doménové sokety a jejich použití v Javě. Předáme si souborové popisovače (FD) z rodičovského procesu potomkovi a ukážeme si princip socket activation. Nakonfigurujeme si služby v klasickém xinetd i moderním systemd a nakonec propojíme Jetty a Apache HTTPD pomocí unixového soketu.

Logo OpenJDK (průhledné 1)

Půl roku vývoje vpsAdminOS: blížíme se spuštění produkčního serveru

červen
04
vpsFree.cz

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.

Hra Raubíř Ralf

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

Opus magnum

červen
02
misantrop

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…

DOOM SIGIL – Klenot od Romera

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. ;-)

(Téměř) rok na Silverblue

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

Pomalé ZFS – jak malé jsou „malé“ soubory?

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

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

Na svém dnešním zasedání valná hromada Sdružení pro internetový rozvoj (SPIR) volila nové členy výkonné rady. Znovuzvoleno bylo 13 z celkem 15 členů. Výkonná rada na svém prvním zasedání za dva týdny zvolí předsednictvo složené z předsedy a dvou místopředsedů.

Členové SPIR na dnešním zasedání valné hromady schvalovali činnost sdružení za uplynulý rok, plány pro další volební období a volili členy nové výkonné rady. Většina z členů původní výkonné rady obhájila svůj mandát na další období: Marek Antoš (Internet Info), Petr Bednář (AdActive), Karel Brýna (Tiscali Media), Tomáš Búřil (Dentsu Aegis Network Czech Republic), Michal Feix (Seznam.cz), Daniel Grunt (FTV Prima), Michal Hanák (MAFRA), Jaroslav Kábele (ČTK), Martin Kyncl (TV Nova), Martin Picek (Mindshare), Martin Šebesta (OMD Czech), Libuše Šmuclerová (Czech News Center), Michael Štádler (Adform). Personální změnou je Štěpán Burda, který nahradil Romana Latuskeho (Economia) a novým členem výkonné rady se stal Jan Bambas z Universal McCann. Za dva týdny proběhne první zasedání výkonné rady, která ze svého středu zvolí nového předsedu a dva místopředsedy.

Máme dvoufaktorové přihlašování do vpsAdmin kvůli vyšší bezpečnosti

květen
22
vpsFree.cz

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.

Školení WordPressu

květen
21
Vlastimil Ott
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

Konference OpenCamp Bratislava 2019

květen
20
Josef Jebavý
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á...

Předvolební 2019

květen
20
Franta Kučera

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.

Jak vytisknout poznámky z PowerPointu

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

Pozvánka na 164. sraz OpenAltu – Brno

květen
16
Openalt.org

Pro letošní květnový sraz OpenAlt bylo vybráno téma voda a ryby, proto se sejdeme v pátek 17. května od 18 hodin na přehradě v restauraci Přístav u Vodů. Pro ty co přijedou dříve se nabízí procházka po okolí, aby jim vyhládlo na nějakou rybí pochoutku. Místo je zamluveno u stolu vzadu za barem s výhledem na přístaviště.

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ů

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

Vzhledem k nejistotě, která na trhu vládne v mezidobí mezi již přijatým GDPR, jehož některé výkladové aspekty jsou postupně upřesňovány, a budoucím nařízením ePrivacy a ve světle rozhodnutí zahraničních regulátorů ve specifických případech týkajících se platnosti či neplatnosti získaných souhlasů, usiluje Sdružení pro internetový rozvoj (SPIR) o vytvoření co nejstabilnějšího prostředí pro vydavatele a zároveň co nejjednotnějšího a nejpřehlednějšího prostředí pro uživatele internetu.

Pro potřeby českého trhu SPIR, i po konzultacích s Úřadem pro ochranu osobních údajů, stále považuje za dostatečný souhlas pro umísťování cookies pro potřeby cílené reklamy povolením cookies v prohlížeči. Nicméně evropští i globální partneři začínají vyžadovat po českých subjektech dokládání standardizovaných souhlasů, které splňují požadavky IAB Europe Transparency and Consent Framework (TCF).

Ze situace na trhu je patrné, že nezapojení se do TCF povede nevyhnutelně k vyloučení příslušného českého subjektu z globálního či evropského reklamního ekosystému, a tudíž praktické likvidaci příslušného subjektu. Souhlasy získané jinak, než v souladu s TCF nebudou minimálně hlavními obchodními partnery přijímány jako platné. 

Z tohoto důvodu SPIR doporučuje vydavatelům, aby se zapojili, pokud to bude nezbytné pro monetizaci jejich reklamního inventory, do TCF a dodržovali níže uvedené standardy. Níže uvedené doporučení pro UI odpovídá standardům TCF, které je nezbytné dodržet, má-li být takto získaný souhlas považovaný v rámci TCF za platný. 

Vlastní doplnění SPIR, která zpřesňují některá doporučení TCF nebo doporučují z pohledu SPIR nejvhodnější variantu z těch, které jsou nabízeny v rámci TCF, jsou vždy vyznačeny kurzívou a označeny jako „Doporučení SPIR“.

DŮLEŽITÉ: 

Aktuálně se připravuje verze 2.0 TCF, která má reagovat na některá rozhodnutí evropských dozorových orgánů. Nová verze má být připravena k nasazení na podzim 2019, přičemž verze 1.0 má být definitivně stažena v prvním čtvrtletí 2020.

Níže uvedené doporučení je proto vhodné pouze jako přechodné řešení v případě tlaku ze strany silných zahraničních partnerů do doby, než bude připravena verze 2.0. Již nyní je patrné, že souhlasy získané ve verzi 1.0 TCF nebudou kompatibilní s verzí 2.0 a bude tudíž nutné po nasazení nové verze opět přesouhlasovat.

Vzhledem k nastalé situaci SPIR doporučuje nasadit níže uvedené řešení v případě potřeby po přechodné období v minimalistické formě.

Jakmile bude verze 2.0 TCF definitivně připravena, bude SPIR své doporučení aktualizovat.

 

Základní postup:

  1. Najděte si dodavatele CMP řešení, vybírat můžete např. ze seznamu na https://advertisingconsent.eu/cmp-list/
     
  2. Implementujte do svých stránek uživatelské UI pro získávání souhlasu. Můžete využít UI komponentu CMP řešení, pokud ji obsahuje. Dodržujte přitom standardy uvedené v doporučení SPIR.

Kdy by se uživateli měla zobrazit oznámení o zpracování údajů a žádost o souhlas (příp. v případě oprávněného zájmu poučení o možnosti vznést námitku)?

Vydavatelé mohou určit, kdy a jak často se příslušné rozhraní UI/UX zobrazí. Vydavatel může toto také ponechat na poskytovateli UI a/nebo CMP. Uvedené rozhraní by se však mělo zobrazovat alespoň:

  • při prvním vstupu uživatele na stránky, které jsou provozovány z ČR nebo jiné členské země EU (jelikož na tyto země se vztahují ustanovení GDPR);
     
  • pokud vydavatel přidal nového smluvního partnera do seznamu smluvních partnerů a chce tuto skutečnost oznámit a sdělit, že osobní údaje zpracovává nový smluvní partner, a získat k tomu od uživatele souhlas, případně poskytnout informace o způsobu, jakým uživatel může uplatnit své právo vznést námitku vůči využívání daného smluvního partnera.

Doporučení pro UI/UX 

Kombinování účelů zpracování a/nebo smluvních partnerů

O účelech zpracování a/nebo smluvních partnerech je nutno informovat beze změny takovým způsobem, aby bylo uživateli jasné, že každý účel zpracování a/nebo smluvní partner představuje samostatný a odlišný účel a/nebo subjekt.

Volbu ohledně účelů zpracování a/nebo smluvních partnerů může uživatel učinit také en bloc(souborně), tj. nikoliv samostatně.

Aniž by to bylo na úkor ustanovení druhého odstavce, uživatel by měl mít možnost si zvolit účely zpracování a/nebo smluvní partnery jednotlivě nebo po menších skupinách, tj. uživatel by měl mít možnost učinit různá rozhodnutí a volby ohledně některých či všech účelů zpracování a/nebo smluvních partnerů, které se mu zobrazují.

Jazyk uživatelského rozhraní

Uživatelské rozhraní musí podporovat jazyk či jazyky, v nichž se nabízí služba, v jejímž rámci se dané UI zobrazuje. Uživatelské rozhraní může dále podporovat i jiné jazyky, např. jazyky země, z níž uživatel ke službě přistupuje.

Formátování UI/UX

Uživatelské rozhraní musí obsahovat dostatečně transparentní informace o zpracování, uvedení účelů zpracování a smluvních partnerů. 

Žádost o souhlas může pokrývat celou stránku nebo její převážnou část. Pokud UI nepokrývá celou nebo převážnou část obsahu stránky, musí být zobrazeno zvýrazněným či nápadným způsobem.

Není-li souhlas od uživatele třeba (např. na základě oprávněného zájmu), je možné informace o zpracování osobních údajů zahrnout do snadno přístupné specializované sekce na webové stránce.

Výzva uživateli, aby se vyjádřil podrobně k jednotlivým účelům zpracování a partnerům, musí být zobrazena v rovnocenném postavení jako žádost o souhlas tak, aby nevznikal dojem, že jedna volba či možnost je upřednostňována před jinou. Vydavatelé musejí nabízet možnost získat podrobnější informace, v jejichž rámci by měla být uživateli nabídnuta možnost udělit souhlas pro všechny nebo jen pro některé účely a stejně tak případně pro všechno nebo některé partnery. Vydavatelé mohou (ale nemusí) nabízet uživateli možnost odmítnout zpracování osobních údajů. 

Doporučení SPIR:

SPIR doporučuje označit tlačítko nabízející podrobnější volby způsobem, z něhož je jasně patrné, že se nejedná pouze o další informace, ale skutečně nastavení, které uživatel může přizpůsobit svým preferencím (např. Podrobnější nastavení, Další volby, Nastavení vlastních preferencí).

SPIR doporučuje umožnit uživateli zavřít banner prostřednictvím tlačítka x, nikoliv samostatným tlačítkem, které explicitně znamená nesouhlas (např. Nesouhlasím, Ne, Odmítám...). SPIR se domnívá, že volba takového „nesouhlasného“ tlačítka v uživateli vyvolává mylný dojem absolutního, a tudíž trvalého odmítnutí, a opakované výzvy s žádostí o souhlas tak mohou uživatele obtěžovat a vést k vyššímu počtu stížností. Použití „zavíracího“ tlačítka bude spíše vnímáno jako dočasný nesouhlas, resp. nesouhlas pro tuto chvíli. 

  1. ÚROVEŇ

Uživatelské rozhraní (UI) musí sdělovat následující informace v první vrstvěinformací, které jsou zobrazovány v souladu s prvním odstavcem:

  • skutečnost, že se osobní údaje zpracovávají, a příklady zpracovávaných osobních údajů;
  • účely zpracování osobních údajů a operace používané smluvními partnery na podporu těchto účelů;
  • skutečnost, že údaje zpracovávají třetí osoby, a odkaz na ucelený seznam takových třetích osob;
  • možnost uplatnit volby, resp. vyjádřit souhlas a možnost tyto volby (souhlas) kdykoli změnit.

V první vrstvě se tedy může zobrazit přehled možností formou rozklikávací (rozbalovací) nabídky, která po jejímž rozkliknutí (rozbalení) se uživatel dostane do vrstvy druhé.

  1. ÚROVEŇ

Následující informace může UI sdělovat již v první vrstvě, nejpozději ovšem ve vrstvě druhé, která je snadno přístupná z vrstvy první, zobrazené v souladu s odstavcem prvním:

  • účely zpracování osobních údajů včetně standardní definice takových účelů;
  • smluvní partneři, kteří osobní údaje zpracovávají.

Příklady způsobů, kterými lze zobrazit seznam účelů zpracování a smluvních partnerů formou druhotných obrazovek zahrnuje mimo jiné odkaz nebo rozbalovací nabídku.

Seznam účelů zpracování a/nebo smluvních partnerů zobrazených v rámci UI musí mít následující vlastnosti:

  • musí obsahovat minimálně jméno smluvního partnera, odkaz na jeho politiku ochrany osobních údajů, účely zpracování a související funkce.

Vydavatelé mohou umožnit uživatelům označit nebo odznačit jednotlivé účely zpracování a/nebo smluvní partnery. Je na vydavatelích, jakým způsobem se rozhodnou tyto možnosti zobrazit. Vydavatelé mohou zároveň uvést případné důsledky plynoucí z jednotlivých voleb vybraných uživatelem.

Doporučení SPIR: 

SPIR doporučuje jako výchozí volbu ponechat jednotlivé účely a partnery zaškrtnuté tak, aby uživatel, který s některou položkou nesouhlasí, ji odškrtl. Následně je potřeba toto nastavení potvrdit, čímž je splněn požadavek opt-in.

Účely zpracování:

  • Ukládání údajů a přístup k nim[1]
  • Personalizace[2]
  • Výběr, zobrazování a reporting reklamy[3]
  • Výběr, zobrazování a reporting obsahu[4]
  • Měření[5]


Doporučení SPIR: 

SPIR doporučuje zvážit skutečné účely zpracování. Pokud vydavatel a jeho partneři zpracovávají data za jinými než uvedenými účely, je nutné seznam o příslušné účely rozšířit.

Jak často musí být daný text koncovým uživatelům zobrazován?

Pokud se koncový uživatel vyjádří ke zpracování a označí určité volby, může vydavatel zobrazit potvrzení volby, kterou uživatel učinil, spolu s informacemi, jak je možné toto nastavení později změnit.

Pokud se koncový uživatel nevyjádří, ale místo toho se přesune na [stránku] [mob. aplikaci] a začne internetové stránky používat, znamená to, že souhlas neudělil. Oznámení by se mu pak zobrazit minimálně podruhé, případně častěji. Vydavatel by měl v patičce stránky zobrazit připomenutí s odkazem na zásady ochrany osobních údajů, kde je možné nastavení změnit.

Podrobné standardy TCF v.1.0 naleznete na https://advertisingconsent.eu/.

 

[1]Příklad textu odpovídajícího TCF: Údaje ukládáme a zpětně přistupujeme k datům a informacím, které už jsou na vašem zařízení uloženy – např. reklamním identifikátorům, identifikátorům zařízení, souborům cookies a dalším podobným technologiím.

[2]Příklad textu odpovídajícího TCF: Shromažďujeme a zpracováváme informace o tom, jak naše služby používáte, a následně je využíváme pro personalizaci reklamy nebo obsahu. Tato data mohou být využita i na dalších webových stránkách a aplikacích, ať už našich, nebo našich smluvních partnerů. Údaje o obsahu webových stránek nebo aplikací, které navštěvujete, zpravidla využíváme pro odvození vašich zájmů, na jejichž základě vám následně zobrazujeme reklamu nebo doporučujeme obsah.

[3]Příklad textu odpovídajícího TCF: Shromažďujeme informace o vašich zájmech, o reklamách, které jsme vám zobrazili, o frekvenci jejich zobrazení, času a místě a zda jste v souvislosti s danou reklamou provedli nějakou akci (například klik na reklamu nebo nákup) a slučujeme je s již dříve uloženými daty. To nám umožňuje lépe vybírat reklamu, kterou vám zobrazujeme, a následně vyhodnotit její účinnost. V této souvislosti nesledujeme údaje, na jejichž základě provádíme personalizaci obsahu nebo reklam v rámci ostatních webů, aplikací nebo služeb, ať už našich, nebo našich partnerů.

[4]Příklad textu odpovídajícího TCF: Shromažďujeme informace o vašich zájmech, o obsahu, který jsme vám zobrazili, o frekvenci jeho zobrazení, času a místě jeho zobrazení a zda jste v souvislosti s daným obsahem provedli nějakou akci, například klik na odkaz, a slučujeme je s již dříve uloženými daty. To nám umožňuje lépe vybírat obsah, který vám zobrazujeme, a následně vyhodnotit jeho účinnost. V této souvislosti nesledujeme údaje, na jejichž základě provádíme personalizaci obsahu nebo reklam v rámci ostatních webů, aplikací nebo služeb, ať už našich, nebo našich partnerů.

[5]Příklad textu odpovídajícího TCF: Sledujeme informace o vašich zájmech, o obsahu, který jsme vám zobrazili, o frekvenci jeho zobrazení, času a místě jeho zobrazení a zda jste v souvislosti s daným obsahem provedli nějakou akci, například klik na odkaz, a slučujeme je s již dříve uloženými daty. Tyto informace slučujeme s daty, která o vašem chování máme z minulosti. Tyto informace nám umožňují změřit, jaká je úspěšnost obsahu, který vám zobrazujeme. V této souvislosti nesledujeme údaje, na jejichž základě provádíme personalizaci obsahu nebo reklam v rámci ostatních webů, aplikací nebo služeb, ať už našich, nebo našich partnerů.

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

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

Sdružení pro internetový rozvoj (SPIR) na základě konzultací s členskými firmami doporučuje v případě, kdy uživatel po firmě žádá informace o tom, jaké jeho osobní údaje (a zejména pak nejrůznější online identifikátory) tato firma zpracovává, postupovat následujícím způsobem:

  1. SPIR doporučuje odpovídat na všechny dotazy uživatelůbez ohledu na to, zda jim budou požadované informace poskytnuty či nikoliv. Kultivaci internetového prostředí a posilování důvěry uživatelů vůči digitálnímu byznysu přispívá právě fungující komunikace. Ostatně povinnost odpovědět na dotaz i v případě odmítnutí poskytnutí údajů vyplývá přímo z čl. 12 GDPR.
     
  2. Kontaktuje-li uživatel společnost prostřednictvím e-mailu, SPIR doporučuje, aby mu firma poskytla pouze informace vztahující se k této e-mailové adrese. Žádá-li uživatel o informace vztahující se k jiným e-mailovým adresám než k té, z níž byla žádost zaslána, SPIR doporučuje požádat uživatele, aby svou žádost poslal znovu vždy z konkrétní e-mailové adresy, aby byla zajištěna rozumná míra ztotožnění žadatele s požadovanými osobními údaji a nedošlo k tomu, že žadateli budou poskytnuty informace o jiné osobě.
     
  3. SPIR doporučuje posuzovat každou jednotlivou žádost zvlášť a zejména pak zohledňovat míru rizikovosti údajů, které firma o uživateli zpracovává a které uživatel po firmě požaduje. Míře rizika musí odpovídat požadavky na ztotožnění uživatele s požadovanými daty. V případě vyššího rizika lze žadatele požádat o další identifikaci (v souladu s čl. 12 odst. 6 GDPR). Míra rizikovosti by měla být zohledněna také při rozhodování o tom, jakým způsobem budou údaje poskytnuty. V odůvodněných případech by měly být nad rámec elektronické odpovědi využity ještě jiné, bezpečnější metody poskytnutí citlivých informací (např. zaslání výpisu do datové schránky nebo přímo na ověřenou adresu, a nikoliv e-mailem na adresu, ke které může mít přístup jiná osoba), případně by měly být údaje odeslány zašifrovaně s tím, že heslo k odemknutí souboru bude předáno jiným komunikačním kanálem. 

V případě pochybností ohledně identifikace žadatele a při vysoké míře rizika doporučuje SPIR s touto situací žadatele seznámit, a pokud uživatel neposkytne dodatečnou identifikaci, jeho žádosti nevyhovět.

Pozvánka na 164. sraz OpenAlt – Praha

květen
13
Openalt.org

Květnový pražský sraz spolku OpenAlt se koná již tento čtvrtek – 16. 5. 2019 od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Tématem pro diskusi jsou tentokrát svobodné mobilní telefony.

pozvánka na sraz: Openmoko + RISC-V + SIM800

10 nejlepších značek kávy podle Have I Been Pwned

květen
08
Michal Spacek

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 🙃

„nescafe“: Oh no – pwned! This password has been seen 7,708 times before

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.

Suchobijci.cz - verze 0.1

květen
05
Petr Soukup

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

Jak přenést kontakty z Google na iCloud

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

Samsung Galaxy Buds: první zkušenosti

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.

Terraform provider pro vpsAdmin: spravujte infrastrukturu automatizovaně

květen
02
vpsFree.cz

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í

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

IAB Europe vydalo k připomínkám veřejnosti verzi 2.0 GDPR Transparency & Consent Framework.

Tiskovou zprávu naleznete zde.

Připomínky lze zasílat do 25. 5. 2019, informace k zasílání připomínek naleznete zde.

Připraveny jsou i webináře, na kterých se budou probírat navrhované změny:

  • registrace na webinář TCF v2.0 pro vydavatele zde,
  • registrace na webinář TCF v2.0 pro vendory a CMP zde.

Více informací o GDPR Transparency & Consent Framework naleznete na stránce https://advertisingconsent.eu