Planeta.OpenAlt.org

V těchto dnech je to přesně rok, co mám doma 3D tiskárnu Průša i3 MK3 (po předchozích RepRap Air ze dřeva a originální Průša i3 MK2). Po úvodních problémech způsobených jen a pouze vadným filamentem (sice od Průši, ale fakticky z Plasty Mladeč, kde tehdy globální dodavatel poslal várku PET granulí s jinou tavnou teplotou a všechno se tím podělalo) jsem se s MK3 spřátelil a teď po roce jsem s ní byl tak spokojen, že jsem se rozhodl napsat pochvalný blog post. Měl začínat těmito slovy:

extruder zezadu - ve svazku ohnutých drátů dojde opakovanými pohyby k nalomení

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

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

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

Pracovní dataset a pool

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

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

Testovací archiv

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

Objektů celkem	195 762
Souborů	187 835
Adresářů	7 927
Souborů na adresář	24
Velikost archivu	148 GiB
Průměrná velikost souboru	830 kiB

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

Testy na ZFS

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

Rozbalení dat na dataset se sync=standard:

Rychlost	72 MB/s
Soubory za čas	89 souborů / s

A na datasetu s sync=disabled:

Rychlost	71 MB/s
Soubory za čas	87 souborů / s

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

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

dataset sync standard	137 s
dataset sync disabled	143 s

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

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

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

dataset sync standard	1979 s	95 souborů / s
dataset sync disabled	2179 s	86 souborů / s

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

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

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

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

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

No ale vyzkoušel jsem to:

ZFS clone

445 s

442 souborů / s

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

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

XFS na pomoc

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

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

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

Rozbalení archivu	94 MB/s	116 souborů / s
Mazání archivu	57 s !!!	3295 souborů / s

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

Grafy

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

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

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

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

Závěr

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

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

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

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

Relační SQL databáze jsou stálicí a hlavním typem databází i v roce 2019. SQL máme mnoho například embedded databázi SQlite. Výborné a nejčastěji používané jsou MySQL/MariaDB aPostgreSQL.

Obrázky z Krkonoš použitelné jako pozadí pracovní plochy monitoru. Kvalita použitelná určitě pro notebook, větší monitor jsem nezkoušel.

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

28,6 miliard korun investovali zadavatelé do internetové reklamy v roce 2018. Více než polovina obchodů proběhla programaticky. tereza.tumova@… St, 03/06/2019 - 13:05

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

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

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

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

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

Mafia I

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

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

Wolfenstein 3D

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

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

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

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

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

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

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

Online marketingové špičky míří na IAC 2019 tereza.tumova@… Čt, 02/28/2019 - 19:37

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

Ahojte všichni,

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

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

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

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

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

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

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

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

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

3. čas pro diskuzi na mailing listech

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

5. konec Schůze

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

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

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

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

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

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

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

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

Díky ještě jednou.

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

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

Tisková zpráva IAB Europe reagující na stížnosti proti společnostem IAB Tech / IAB Europe a Google tereza.tumova@… Po, 02/25/2019 - 10:10

AdMonitoring rozšířil své výstupy o programatik tereza.tumova@… Po, 02/25/2019 - 09:40

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

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

I virtuální server musí nakonec běžet na nějakém fyzickém hardwaru. Proto i na fyzické počítače je potřeba občas instalovat operační systém Linux. Tentokráte se mě do rukou dostaly servery HPE ProLiant DL320e, které jsou oblíbené pro svůj poměr cena výkon.

Profesní sdružení považují návrh novely trestního zákoníku za nevhodný způsob obrany svobody slova tereza.tumova@… Pá, 02/15/2019 - 08:00

Mám už dlouho rozepsaný monstrčlánek na téma notoricky chybných očekávání a mylné intuice lidí, kteří se bez zkušenosti nad rámec běžných uživatelů dostanou do nějaké role v softwarovém vývoji. Pak šlo ale kolem fantastické Twitterové vlákno Davida Majdy a já jsem si uvědomil, že v těch pár řádcích je ve skutečnosti obsaženo jádro všeho, co jsem lopotně psal a mnohem víc. Se svolením autora proto thread překládám do češtiny a doplňuji pouze pár vlastních poznámek ve vztahu k původnímu tématu.

Před rokem jsem si pořídil první pořádné bezdrátové sluchátka. Musím říct, že s Fedora Workstation fungují bezvadně. Spárují se, spojí se, zvuk je automaticky přesměrovaný do sluchátek. Když už spárované sluchátka zapnu, notebook se s nimi automaticky spojí. Jen ten zvuk není úplně ideální.

Zatímco „po drátě“ jde zvuk nekomprimované podobě, Bluetooth má omezenou propustnost a proto se musí použít nějaký kompresní kodek. Můžete použít prakticky libovolný. Aby byl ale použitý, musí jej podporovat obě strany. A počet kodeků, který bluetooth zařízeními podporovaný, je omezený: AAC (částečně volně použitelný, má asi nejširší podporu, protože to je jediný kodek, který podporuje iPhone), AptX (proprietární a patentově chráněný, taktéž velmi rozšířený), AptX-HD (opět proprietární a patentově chráněný, vylepšený AptX s vyšším bitratem), LDAC (volně dostupný  v Androidu, nejvyšší bitrate, asi nejlepší dostupný kodek), MP3 (ano, i ten se dá použít, dnes už je dokonce volně použitelný, ale podporuje ho minimum zařízení).

A pak je tu SBC, základní kodek první generace, který je součástí standardu Bluetooth a podporují ho všechna zařízení. Jeho poměr velikost/kvalita je oproti výše zmíněným kodekům špatný. Problém taky je, že většina zařízení dneska zvládne bitrate přes 500 kbps, ale při použití SBC jej omezuje na 320 kbps nebo ještě méně, což je u tohoto kodeku vážně málo.

Moje sluchátka podporují SBC, AAC, AptX, AptX-HD, LDAC. Kromě SBC tedy i všechny aspoň trochu rozšířené pokročilé kodeky. Bohužel na Linuxu se nakonec použije SBC, protože žádný jiný není k dispozici, a sluchátka za šest tisíc hrají jako šumítka za pár stovek. Dnes poslouchá hudbu už prakticky jen na Spotify, které streamuje v OGG 320 kbps. Tento stream se ale v notebooku překóduje do SBC, což znamená docela výraznou ztrátu kvality.

Když jsem o tom přemýšlel před necelým rokem, uvědomil jsem si, že jsem četl, že Sony uvolnilo pro Android kodek LDAC, aby tak mělo konkurenční výhodu oproti AptX-HD, jehož předchůzce AptX je na Androidu taky velmi rozšířený, ale není součástí samotného Androidu a výrobci mobilů za jeho použití musí platit Qualcommu. Říkal jsem si, že pokud je součástí Android Open Source Projectu, musí být uvolněný pod nějakou otevřenou licencí. A taky že byl! Nachází se tam pod licencí Apache 2.0, která zaručuje to, že i když má Sony na daný kodek patenty, nemůže nic vymáhat po uživatelích tohoto kódu.

Zjistil jsem také, že Bluez s kodekem LDAC počítá a pokud je k dispozici, dokáže se na jeho použití s druhou stranou domluvit. Co ale chybělo, bylo rozšíření pro PulseAudio, které by se staralo o převod zvukového streamu do LDACu. Nebylo to úplně triviální množství práce, tak jsem to přeřadil do škatulky „Co bychom mohli implementovat v budoucnu v PipeWire“. PipeWire má totiž výhledově PulseAudio nahradit.

Včera jsem se ale dozvěděl, že takové rozšíření PA mezitím vzniklo. Kromě LDACu podporuje také AptX, AptX-HD a AAC. Ty jsou, jak už jsem zmínil, patentově chráněné a onen modul pro ně používá ffmpeg. Ty tak ve Fedoře hned tak podporovat nebudeme. Zjistil jsem ale taky, že libldac už je ve Fedora package review a zrovna včera dostal kladný právní posudek. To znamená, že už stačí dostat do Fedory jen ten modul a uživatelé se sluchátky podporujícími LDAC budou mít automaticky ve sluchátkách mnohem lepší zvuk.

Původně jsem si myslel, že budeme moct podporovat i AAC, což by vzhledem k jeho rozšířenosti bylo super, ale kodek, který je momentálně ve Fedoře nepodporuje všechny profily, což se může projevit na funkčnosti nebo kvalitě streamu.

Každopádně někdo už zabalil jak onen modul, tak libldac a já jsem se rozhodl to vyzkoušet. A ono to na Fedoře 29 skutečně fungovalo, LDAC se začal používat pro streaming přes Bluetooth:

Nemám netopýří uši, ale rozdíl v kvalitě zvuku jsem poznal od prvního okamžiku. Poslouchám na těch sluchátkách hudbu z notebooku už druhý den a je to opravdu jiná káva. Výsledoval jsem, že PulseAudio při hraní vytěžuje procesor z 3-5 %. Nedělal jsem srovnání s původním SBC.Předpokládám, že kódování do LDACu bude o cosi náročnější, ale u průměrného stroje to bude rozdíl neznatelný. Někteří uživatelé si stěžovali na latenci, ale myslím si, že to je primárně problém sluchátek, které si nejsou schopné domluvit latency off-set. Já mám video s audiem synchronizované.

Pokud se nepletu, dělá to z Linuxu první desktopový systém, který LDAC podporuje. Doufám, že se nám to podaří dostat už do Fedory 30. Společně s podporou AptX, AptX-HD a AAC (které budou v případě Fedory vyžadovat instalaci balíčku z RPMFusion) tak bude mít vůbec nejširší podporu pokročilých kodeků mezi systémy. Všichni ostatní podporují jen SBC a potom podmnožinu z těch pokročilých.

Kromě výše zmiňovaného modulu se vyvíjí podpora také přímo v PulseAudiu. Ta má pokrývat stejné kodeky. Ale také SBC Ultra High Quality (SBC s vyšším bitratem), AptX Low Latency a FastStream (kodeky pro obousměrný provoz použivané pro hovory). Vzhledem k tomu, že vývoj probíhá v kontaktu s upstreamem, má i větší šanci na to, že se stané trvalou součástí PulseAudia.

Mobilní telefon je úžasný vynález, který podle mě nespadá do kategorie „rychlejší koně“. Tedy do kategorie vynálezů, které si představujeme jako současnou věc, jen lepší, rychlejší, menší, výkonnější. Tohle prostě nikdo nepředpověděl. Dnes nikoho nezajímá, že je to přenosný komunikační přístroj, ačkoliv před 30 lety nebyly u nás běžné ani telefony stacionární. Zajímají nás jiné ...

Přečíst celý článek > K čemu používáte mobilní telefon, kromě telefonování?

Kategorii Bydlení – prodej navštívilo v lednu téměř půl milionu nových uživatelů tereza.tumova@… St, 02/06/2019 - 13:22

Stále spousta webů, často i eshopů nemá zabezpečený web. Proto jsem jsem se rozhodl vysvětlil proč mít web zabezpečený pomocí protokolu HTTPS a SSL certifikátu a jak správně udělat přesměrování z HTTP na HTTPS.

Také Vás tak bavily staré hry? Vzpomínáte občas s láskou na pecky jako byla Contra, Mario, Mortal Kombat, Golgen Axe, Mario

Příspěvek Postavte si doma retro herní konzoli snadno a rychle pochází z Spajk.cz

V článku chci předvést, jak jednoduché je nechat si vyrobit krásné plošné spoje. Už jsem tu na blogu párkrát popisoval, jak to jde v Česku, v Číně a v USA, ale dneska se zaměřím přímo na jednoho známého výrobce, který má web nazvaný Seeed Studio Bazaar.

Na webu běží jednak e-shop, a pak také služby sdružené pod hlavičkou "Fusion PCB/PCBA". Zvládají plošné spoje od návrhu až po osazení, ale to si všecko rád udělám sám - stačí mi jen vyrobit ty desky, takže jdu přímo na Fusion PCB/PCBA.


Na této vstupní stránce je potřeba se nejdřív přihlásit, vpravo nahoře klikem na "Sign In". Samozřejmě když ještě nemám účet, tak si ho musím založit. Není to problém, nabízejí i zrychlené přihlašování přes Facebook (které jsem nikdy nezkoušel).

Pak už stačí kliknout na "Add Gerber Files" a nahrát tam třeba ZIP archív s vyexportovanými soubory z návrhového programu v Gerber formátu. Když nevím, jak je správně vygenerovat, můžu kliknout na nápovědu "How to generate Gerber files". Na stránkách mají podrobný popis pro osm nejznámějších programů pro návrh plošných spojů, což je super.

Horší je, že v tom návodu mají chyby. Konkrétně pro můj oblíbený KiCad na fotce obrazovky ukazují, že má člověk zatrhnout pozice otvorů v milimetrech, ale to by dopadl! Musí to být v palcích, jinak je zle. Naštěstí je to vidět v náhledu, který se po načtení ZIP archívu s Gerber soubory ukáže.



Ten náhled (dostupný po kliku na "Gerber Viewer") je mimořádně důležitý. Umí zobrazit výsledný vzhled, obě strany, každou vrstvu klidně zvlášť. Je zásadně potřeba zkontrolovat, že Seeed Studio Fusion tu desku vidí stejně, jako to člověk nakreslil v návrhovém programu. Mělo by to sedět, ale např. v mém případě Seeed Studio Fusion nikdy nerozpozná skutečně rozměry plošného spoje správně - na obrázku výše vidíte, že hádá rozměry 135 x 130 mm, což je jednak špatně a hlavně bych se kvůli tomu nedoplatil. Proto jsem vedle vyplnil skutečně rozměry desky, které jsou 99 x 98 mm.

Rozměry desky totiž přímo ovlivňují výslednou cenu a to velmi zajímavým způsobem: pokud jsou menší než 100 x 100 mm, tak výsledek stojí $4.90 (tedy zhruba 110 Kč), ale jakmile překročíme byť jen jeden z těchto dvou rozměrů, cena naskočí třeba na pětinásobek. Takže je dobré se vejít do těch 10 x 10cm, pak je to velmi levné.


V dalších krocích níže si postupně vybereme počet vyrobených desek - tu je velmi zajímavé, že 5 nebo 10 desek stojí pořád stejných $4.90, teprve při vyšších počtech hotových desek se cena začne zvyšovat. Ostatní parametry (např. tloušťka desky, tloušťka mědi, minimální otvory, mezery atd.)  nechávám výchozí. Super je, že u Seeed Studio Fusion je změna barvy desky bez příplatku, takže jsem si dovolil místo klasických zelených objednat modré.

V pravém sloupci je neustále vidět souhrn případné objednávky včetně výsledné ceny (bez poštovného). Takže člověk si může pohrát s parametry desky a vždy vidí, jak která změna ovlivňuje cenu. Dokud neklikne v pravém sloupci na "Add to Cart" (vložit do košíku), nic se neděje.

Do košíku se dá postupně vložit i několik různých desek. Pokud se člověk chystá zaplatit rychlejší a dražší poštovní společnost, je lepší ji vytížit objednávkou více desek. Pokud naopak člověk chce použít levnou poštu, tak ta se počítá podle hmotnosti výsledné zásilky, takže je levnější objednat si méně desek, nebo je udělat co nejmenší.


Až je v košíku všechno, co tam má být - dá se ověřit klikem vpravo nahoře na ikonu košíku, tak pak stačí kliknout na "GO TO CHECKOUT". Na další stránce je ještě jednou přehled všeho, co objednávám/kupuju:


Po kliku na "CHECKOUT SECURELY" se na další stránce zadává doručovací adresa:

No a na další stránce ("2. Shipping method") to začne být zajímavé:

Normálně by člověk zvolil nejlevnější dopravu pomocí Singapore Post, aby cena dopravy nebyla násobně vyšší než cena samotných desek. Ovšem doručení by trvalo tak tři týdny. Jelikož jsem si naobjednával víc desek, tak cena Singapore Post poštovného vyskočila kvůli hmotnosti výsledného balíčku z běžných cca 8 dolarů až na $18.31 - a to už se vyplatí raději zvolit DHL za $23.66, ale s doručením téměř do druhého dne!

Na další stránce se vybere, čím se zaplatí. Osobně platím PayPalem, takže nic s platební kartou neřeším:


Po kliku na "Continue to Payment", přesměrování na PayPal bránu a zaplacení tam se načte poslední stránka Seeed Studio Fusion služby:


No a pak začnou chodit informační maily. Konkrétně u mě to časově probíhalo takto:

• objednávku jsem zadal 22. ledna v 12:41
• maily o začátku výroby desek přišly 23. ledna v 10:52 (první dvě desky) a v 19:41 (druhé)
• 29. ledna v 7:14 přišel mail od Seeed Studia o odeslání hotové zakázky
• 29. ledna v 6:55 přišel mail od DHL "Vaše zásilka je na cestě" (start z Hong Kongu)
• 31. ledna v 7:28 přišel mail od DHL "Doručení proběhne dnes"

Pečlivě vakuově zabalené v bublinkové fólii. A po rozbalení takováto nádhera:

WiFi Teploměr

bezdrátové čidlo na CR2032 baterii

bezdrátové čidlo na dvě AAA baterie

Desky vypadají prostě dobře. Ořez, cestičky, otvory, prokovy, frézované díry, velké vrtané díry, nepájivá maska, popisy - zkrátka všechno jak má být. Akorát mám v pracovně tmu, tak to neumím vyfotit slušně - s bleskem se to leskne, bez blesku je to tmavé.

Nelze si nevšimnout, že využívám základního rozměru 10x10 cm na maximum. Desky potřebuju menší, ale naskládám je vedle sebe a naznačím, kde je potřebuji naříznout - a Seeed Studio to všechno udělá a já pak jednu desku rozlámu v ruce klidně na 12 malých destiček. Tomuto se říká panelizování, psal jsem tu na blogu návod jak na to, a co jsem se to naučil, používám to neustále.

Mimochodem, ty panelizační řezy naznačuju čárami ve vrstvě pro ořez obvodu desky, a to nejspíš zmate algoritmus na výpočet skutečných rozměrů desky. Proto jsem je musel zadávat ručně. Je pravděpodobné, že kdo tam ty čáry navíc nemá, tak mu to výsledné rozměry uhádne správně.

Tož tak je to s výrobou plošných spojů u Seeed Studio Fusion. Používám je na střídačku už aspoň čtyři roky a zatím nikdy nezklamali. Doufám, že kvalitu a cenu udrží i nadále.

Aktualizace článku

• 30.1. Chrome 72 varuje při použití TLS 1.0 nebo TLS 1.1

Protokol TLS (Transport Layer Security) je základem HTTPS a jeho první verze vyšla v roce 1999. Byl to nástupce protokolu SSL 3.0 z roku 1996, ten už prohlížeče nepodporují tři roky a váš server by taky dávno neměl. Platební brány a weby pracující s platebními kartami nesmí TLS 1.0 používat od letošního léta.

Verze TLS 1.1 vyšla o pár let později, v roce 2006, ale podobně jako TLS 1.0 používá překonané algoritmy MD5 a SHA-1. TLS verze 1.0 ani 1.1 prohlížeče běžně už nepoužívají:

• Google tvrdí, že s těmito protokoly je v Chrome uskutečněno jen 0,5 % HTTPS spojení, od verze 72 se navíc v developer tools objevuje varování při použití TLS 1.0 nebo 1.1
  

  Varování v Chrome 72, vyzkoušejte si ho na odkazech z badssl.com

• V Edge je to prý 0,72 %
• V Safari údajně 0,36 %
• Firefox uskuteční 1,11 % všech HTTPS spojení pomocí TLS 1.0 a 0,09 % pomocí TLS 1.1

Pokud server tyto protokoly stále podporuje, tak hrozí, že útočník donutí prohlížeč použít je namísto bezpečného TLS 1.2 nebo TLS 1.3. Bylo by tedy vhodné je na serveru zakázat, ale předtím je dobré si zjistit, jaké prohlížeče tyto protokoly vyžadují. Už jich moc není, v seznamu nenajdete ani jeden moderní browser.

Handshake simulation

Prohlížeče, které se po vypnutí TLS 1.0 a 1.1 na váš server nepřipojí, můžete zjistit třeba otestováním vlastního webu pomocí nástroje SSL Labs Server Test. Do políčka Hostname zadejte vaší doménu, stiskněte Submit a chvíli počkejte na dokončení testu.

Test vyzkouší nastavení HTTPS na vašem webu, ten by měl ideálně získat známku A nebo A+, kterou ale aktuálně dostanete i když máte staré TLS povolené. Na hodnocení má vliv několik nastavení, které jsem se pokusil krátce vysvětlit ve své přednášce o SSL Labs. Ale tenhle článek není o známkách, níže se budu věnovat převážně jen protokolům TLS.

Ve výsledcích pod informacemi o certifikátech začíná sekce Configuration. V ní uvidíte, které protokoly server podporuje a v části Handshake Simulation jsou uvedeny testované prohlížeče, protokoly a šifry, které ke spojení používají.

„Handshake“ je počáteční část HTTPS spojení, během které se prohlížeč a server domluví na tom, jaké protokoly, šifry a šifrovací klíče budou používat. SSL Labs zkouší simulovat cca 50 různých prohlížečů a výsledky této domluvy pak zobrazí v přehledné tabulce.

Řádek po řádku

Pojďme si rozebrat třeba hned ten první řádek, do detailů kryptografie ale zacházet nebudeme, nebojte:

Android 2.3.7

Simulovaný prohlížeč (obecně HTTPS klient) a verze

No SNI²

Poznámka, která v tomto případě říká, že Android 2.3.7 nepodporuje SNI (Server Name Indication), což je technologie dovolující na jedné IP adrese provozovat více webů na HTTPS, každý s vlastním certifikátem (ta „2“ v „SNI²“ je jen odkaz na poznámku pod čarou) – ve finále to znamená, že pokud chcete podporovat i takto staré Androidy, tak pro váš web musíte mít vyhrazenou IP adresu

RSA 2048 (SHA1)

RSA znamená spoustu věcí, v tomto případě ale označuje typ certifikátu a soukromého klíče, 2048 pak velikost toho klíče a SHA1 algoritmus použitý pro podpis certifikátu, který by se již běžně používat neměl

TLS 1.0

Použitý šifrovací protokol ve verzi, které se zrovna náhodou chceme zbavit

TLS_RSA_WITH_AES_128_CBC_SHA

Použitá šifra, přesněji „cipher suite“, která určuje, jak proběhne výměna klíčů a jaký šifrovací algoritmus se použije

No FS

„FS“ znamená Forward Secrecy a test nám zde naznačuje, že „cipher suite“ se tímto označením nemůže pyšnit a že pokud by mizera získal soukromý klíč ze serveru, tak by mohl rozšifrovat již proběhlou zaznamenanou komunikaci i tu, která teprve proběhne

A teď ten poslední řádek z předchozího obrázku:

Android 7.0

O dost novější verze, že

EC 256 (SHA256)

Byl použit certifikát i soukromý klíč využívající Elliptic-curve cryptography, EC klíče i certifikáty jsou o dost menší (klíč má „jen“ 256 bitů) a zpracovávají se rychleji, podpora je také výborná (já na svém webu používám už jenom EC certifikáty); SHA256 je pak označení pro podpisový algoritmus z rodiny hashovacích funkcí SHA-2, která by se pro certifikáty měla používat

TLS 1.2 > h2

Spojení proběhlo pomocí TLS 1.2, „> h2“ naznačuje, že bylo využito protokolu HTTP/2

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

Použitá šifra, resp. „cipher suite“

ECDH x25519

Upřesnění výměny klíčů v dané „cipher suite“, který proběhla pomocí algoritmu Elliptic-curve Diffie–Hellman s eliptickou křivkou označovanou jako X25519

FS

„Cipher suite“ podporuje Forward Secrecy, takže mizera, který se dostane k soukromému klíči ze serveru nedokáže minulou ani budoucí komunikace dešifrovat

Pohledem na všechny řádky zjistíte, který prohlížeč by použil TLS 1.0 nebo 1.1. Pokud takové prohlížeče již nechcete nebo nemusíte podporovat, tak tyto zastaralé protokoly v konfiguraci vašeho serveru vypněte. Nedávno to udělal např. i Slevomat, viz výsledky testu. A když to mohl vypnout Slevomat, tedy komerční web pro velmi širokou veřejnost, tak vy můžete nejspíš také. Správce serveru by to měl zvládnout, v Apache k tomu slouží direktiva SSLProtocol, v nginx ssl_protocols.

Nepodporované prohlížeče

Na konci sekce Handshake Simulation najdete pod hlavičkou Not simulated clients (Protocol mismatch) prohlížeče, které se v defaultním nastavení chtěly připojit již nepodporovaným protokolem. Pro můj web ta podstatná část vypadá takto, přičemž na obrázku chybí ještě stará Java, knihovna OpenSSL z dob, kdy se po Zemi ještě proháněli dinosauři a Safari verze 5 a 6 na OS X:

Na můj web se nepřipojí ani Chrome 49 na Windows XP, protože ten by potřeboval RSA certifikát, který jsem přestal používat. Pokud browser zvládne TLS 1.2, tak zvládne i EC certifikát, s touhle jedinou výjimkou, takže je můžete v klidu používat. Pokud byste stále potřebovali podporovat i Chrome na Windows XP, tak můžete použít oba typy certifikátů zároveň, pokud to váš server umí a Apache i nginx to umí.

Vypněte nepoužívané věci

Když už budete v tom vypínání starých TLS, tak stejně můžete postupovat u „cipher suites“. SSL Labs Server Test některé „cipher suites“ označí jako slabé („weak“), některé dokonce jako „insecure“, ale pokud je žádný vámi podporovaný prohlížeč nepoužívá, tak je z konfigurace serveru můžete také odstranit. Můj server nabízí jen 5 „cipher suites“, konfiguraci jsem převzal z generátoru od Mozilly, přičemž jsem použil profil „Modern“.

Pokud se o HTTPS zajímáte ještě víc, tak vás rád přivítám na dalším termínu mého školení HTTPS (červen 2019 Praha).