Příspěvky

16

Sítě / Re:T-Mobile LTE & docker pull = katastrofa

« kdy: 27. 05. 2019, 11:21:07 »

Tak jsem po týdnu zpět a T-Mobile se ještě neozval. Na druhou stranu vše už zase funguje - 0% packet loss. Uvidíme jestli se ozve s info kde byl problém.

17

Sítě / Re:T-Mobile LTE & docker pull = katastrofa

« kdy: 21. 05. 2019, 00:03:58 »

Stejne bidne to jede i na interni siti. Hlasil jsem to na servicedesk, tak uvidime.

Až teď mi to došlo Díky, třeba se to někam pohne. Už to řeším více jak týden a ...

18

Sítě / Re:T-Mobile LTE & docker pull = katastrofa

« kdy: 20. 05. 2019, 23:14:30 »

Zajímavé. Když jsem to zkoušel tak jsem neměl problém na Vodafone LTE, WiFi poskytovatel, VDSL. Jediné kde to nefungovalo byl T-Mobile LTE. Až budu zpět, zkusím znovu.

Od T-Mobile se ještě nikdo neozval, resp. ozval, ale následně přeposlal na IT, které mlčí. Zkoušel jsem psát i na https://www.atman.pl (tam jsou servery CloudFlare v PL) a oni provedli pár testů. Směrem od nich k routeru T-Mobile žádný problém není, 0% packet loss.

Teď už zbývá napsat Dockeru, že se jim tam něco děje / dělo. Do konce týdne se k tomu T-Mobile LTE nedostanu abych to zkusil. Jsem zvědav jak to bude vypadat až se vrátím.

19

Sítě / Re:T-Mobile LTE & docker pull = katastrofa

« kdy: 16. 05. 2019, 14:59:26 »

Kód: [Vybrat]

ping -c 10 production.cloudflare.docker.com
PING production.cloudflare.docker.com (104.18.124.25): 56 data bytes
64 bytes from 104.18.124.25: seq=0 ttl=54 time=69.577 ms
64 bytes from 104.18.124.25: seq=3 ttl=54 time=69.271 ms
64 bytes from 104.18.124.25: seq=7 ttl=54 time=79.056 ms
64 bytes from 104.18.124.25: seq=8 ttl=54 time=69.019 ms
64 bytes from 104.18.124.25: seq=9 ttl=54 time=67.798 ms

--- production.cloudflare.docker.com ping statistics ---
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 67.798/70.944/79.056 ms

50% packet loss na production.cloudflare.docker.com :/

20

Sítě / T-Mobile LTE & docker pull = katastrofa

« kdy: 16. 05. 2019, 14:35:22 »

Na jednom místě mám LTE připojení od T-Mobile 100/25 Mbps. Běžná rychlost je 70/15 Mbps. Všechno mi funguje perfektně. Jediná věc, která je víceméně nefunkční je docker pull. Symptomy ...

* rozjede se Downloading,
* po pár MB se to zastaví,
* pak to chcípne na read tcp 192.168.1.68:41990->104.18.121.25:443: read: connection reset by peer & unexpected EOF
* Attempting next endpoint for pull after error: could not get decompression stream: Get https://production.cloudflare.docker.com/registry-v2/docker/registry/v2/blobs/sha...

... a konec. Tenhle konkrétní layer má cca 50MB a nestáhne to víc jak 5-10MB. Jakmile přehodím připojení, nemám problém.

Když zkouším stahovat velké soubory z S3 (2GB), funguje. Všechno funguje, jediná problematická věc je docker pull. Nějaké nápady co by to mohlo být?

21

Hardware / Re:Jakou IP kameru

« kdy: 11. 03. 2019, 16:05:53 »

Pusť si https://www.youtube.com/watch?v=B8DjTcANBx0. Je to sice 5 let staré, ale nedělám si iluze, že by se něco radikálně zlepšilo. Jestli stejným způsobem dělají i cloudové služby, tak potěš koště.

Kup si kameru, která ukládá záznam na kartu, nikam se nepřipojuje, strč ji do samostatné sítě, zakaž ji komunikovat ven a před to si dej VPNku.

Pokud chceš cloud, kup si Angelbox (https://www.angelcam.com/angelbox), vytvoř si svůj Angelbox (https://github.com/angelcam/arrow-client/wiki/Turning-your-ARM-device-into-AngelBox) a nebo si pusť Arrow klienta (https://github.com/angelcam/arrow-client) na čem chceš. Potom jsi schopen dostat do Angelcamu „jakoukoli“ kameru. Myslím, že to je „for free“ bez nahrávání. Pokud chceš i nahrávání, ceník je tady https://www.angelcam.com/pricing. Podobné službě bych věřil víc než těm od výrobce.

P.S. Co si pamatuju, tak na adaptérech (a i samotných kamerách) od DAHUA se dalo vařit kafe. Měl jsem jich pár na test a žádnou z nich bych nechtěl ani zadarmo.

22

Studium a uplatnění / Re:Ověření pracovní praxe

« kdy: 06. 02. 2019, 10:53:59 »

Každá firma to dělá jinak, těžko odpovědět. A každý člověk v té firmě to také dělá jinak. K čemu ti to vlastně je? Chceš jim v CV něco „nakecat“ s tím, že si ověřuješ zda-li to projde? Od začátku špatně. ČR je malá, většinou se stačí poptat pár lidí a hned víš s kým máš tu čest

23

Vývoj / Re:Čo sa stalo s WebAssembly?

« kdy: 06. 02. 2019, 10:39:13 »

Jinak doporučuji neminout zprávičku https://www.root.cz/zpravicky/rustpython-je-implementace-jazyka-python-3-napsana-pomoci-rust/ kde jsou odkazy na RustPython, což je Python v Rustu a celé to běží v prohlížeči (WASM).

24

Vývoj / Re:Čo sa stalo s WebAssembly?

« kdy: 06. 02. 2019, 10:28:27 »

A nechceš se pochlubit víc? Firma ...

Firma je https://www.balena.io/.

Nějaké technologické zajímavosti ohledně wasm targetu

To je tak široce položená otázka, že nevím co na to napsat. Obecně, jak už tu zaznělo, WASM je v podstatě MVP. Má to spoustu limitací, které člověk musí znát. Občas jsem si pořádně nabil, protože jsem začal něco dělat, neodzkoušel to s WASM / JS a pak jsem měl problémy. Musel jsem změnit implementaci v Rustu a nebo přidat nějaký „šílený“ wrapper pro WASM / JS.

Můj předchozí příspěvek zněl asi až moc optimisticky, tak uvedu příklad, který jsem musel řešit. Už jsem tu zmiňoval třeba náhodný generátor. Lidi kolem Rustu se snaží, přidávají podporu pro wasm32 kde to jde, například ...

• https://github.com/rust-random/rand/blob/0.6.5/rand_os/src/wasm32_bindgen.rs

... ale stejně narážíte na špeky, že ne všechny knihovny fungují ...

• https://github.com/uuid-rs/uuid/issues/350

... protože si občas musíte vybrat jestli stdweb, wasm-bindgen, podle toho zapnout / vypnout nějakou vlastnost, cargo to nedělá tranzitivně, takže se stejná vlastnost (jako má rand) musela přidal i do uuid-rs ...

• https://github.com/uuid-rs/uuid/issues/350
• https://github.com/uuid-rs/uuid/pull/351/files#diff-80398c5faae3c069e4e6aa2ed11b28c0

... atd.

Jedna rada, resp. je potřeba si uvědomit, že pokud se vydáte na cestu Rust & WASM, stanete se jedním z pionýrů a budete muset řešit problémy i v ostatních knihovnách, přidávat podporu, ... Když to funguje, tak je to paráda. Jinak musíte přiložit ruku k dílu (PR) a nebo to alespoň nahlásit jako issue. A to nemluvím o Rustích knihovnách, které mají závislosti na C knihovnách a chcete je ve WASM. To už je zase úplně jiná úroveň problémů. Pustit wasm-pack nebo cargo build --target wasm32-unknown-unknown mnohdá nestačí.

Dost mi to připomíná situace kdy jsem v dávných dobách (±20 let) na Linuxu začal řešit uspávání, framebuffery, ... Když to jelo, bezva. Ale občas jsem toho měl plný zuby.

Pokud chcete začít s Rustem & WASM & JS/NPM, tak starovací čára je tady:

• https://github.com/rustwasm/wasm-pack
• https://github.com/rustwasm/wasm-bindgen
• https://github.com/rustwasm/wasm-bindgen/tree/master/crates/js-sys
• https://github.com/koute/stdweb

Pokud C/C++ & WASM, tak tady:

• https://github.com/emscripten-core/emscripten

A to všechno následováno google.com

Jak dlouho používáte Rust, jestli jedete na stable verzi apod.?

Já osobně víc jak 2 roky. Firma taky tak nějak. Od doby co vyšla edice 2018 tak jenom stable. Dříve to byla víceméně kombinace stable & nightly. Nightly jen pro clippy-preview a rustfmt-preview. Teď už to běží na stable, -preview suffix byl odstraněn a nightly tak není potřeba. Suma sumárum, pokud si nehrajeme, tak je všude stable.

25

Vývoj / Re:Čo sa stalo s WebAssembly?

« kdy: 04. 02. 2019, 09:29:41 »

Wasm je vo verzii 1.0, podpora v prehliadačoch výborná: https://caniuse.com/#search=webassembly, ale záujem? Čistá nula. Frontendu naďalej, vlastne ČORAZ VIAC, dominuje JavaScript a React a nikde ani len náznak, že by sa to najbližšie roky zmenilo - po nejakom wasm ani pes neštekne. Čo sa to deje? Kde je ten koniec JS? Obzvlášť tu, na forum.root.cz, tak často skloňovaný v súvislosti s príchodom wasm?

Podle čeho usuzuješ? Třeba Rust & WASM je můj denní chléb. Používáme ho na knihovny kde chceme sdílet kód, který má ve výsledku běžet nativně, v NodeJS a v prohlížeči. Dřív bylo všechno v JS, ale to nám už na IoT zařízeních nevyhovuje, proto tahle cesta. Jeden zdroják a z něho generuju Rust crates (knihovny) a NPM balíčky pro použití v JS.

Ještě to není tak rozšířené, i když už je to lepší, protože nástroje jsou stále nedokonalé. Ve smyslu balení NPM balíčků (wasm-pack, ...), generování JS wrapperu (wasm-bindgen, ...), atd. Funguje to, ale má to své mouchy. A zároveň ještě nedávno nebylo úplně jednoduché napsat něco co běží všude - např. když jsi používal náhodné generátory, ... Teď už je to celkem pohoda.

Třeba CloudFlare přidal WASM workery: https://blog.cloudflare.com/webassembly-on-cloudflare-workers/  To, že to nevidíš neznamená, že se to nikam nehýbe

26

/dev/null / Re:Kolik jste investovali do výrobků Apple ?

« kdy: 24. 01. 2019, 08:31:01 »

Tak už se nedohadujte Ať si každý používá a utrácí za co chce. Osobně mi přijde, že tady ty „hejty“ na Apple jsou od lidí co nikdy neměli víc než jedno jejich zařízení (nebo neměli vůbec žádné) a nezažili ten komfort komplexní integrace všeho se vším. Je mi úplně jedno jestli je Apple leader v inovacích v oblasti HW nebo ne - telefonem nefotím, kravinky jako Face ID jsou fajn, ale ne nutností, ... Foťák v displeji? K čemu? Stále mám např. iPhone SE a budu mít dokud nechcípne. Pokud si dobře pamatuju, Apple nikdy moc nevynikal v tom, že uvede nějakou technologii na trh jako první (kromě začátků iPhone). Apple o tom občas mluví, spíš ne, ale snaží se technologii dotáhnout do lepší použitelnosti a až potom to vydá. Když vezmu Face ID, tak taky nebyl první na trhu, přišel s tím později, ale s diametrálně odlišnou použitelností / spolehlivostí.

Osobně za to platím tolik, protože jsem už línej, nemám čas a nechci řešit nastavování, synchronizaci, kterou Android (čí další systém) nemá tak propracovanou (iMessage, backup, obnova a nastavení nového zařízení, ...). Plus další služby kolem iCloudu, Photos & sdílená alba, ... Chci sáhnout po čemkoli co je po ruce, udělat tam co potřebuju, dodělat to co jsem začal na jiném zařízení, ... aniž bych přemýšlel jestli to tam bude, jak to tam dostanu, ...

Ale to neznamená, že musím „hejtit“ Android. Do detailu ho neznám, občas se podívám co je nového, moc se mi nelíbí, někomu ano, fajn, problém nevidím. Nebo někomu tlačit Apple. Koho to zajímá, tomu klidně všechno rád ukážu, jen nenutím. Tihle fanatičtí zastánci z obou táborů by se měli jít léčit

Pokud bych si měl koupit jenom jedno zařízení, nechtěl jich víc, tak se možná porozhlédnu i jinde. V opačném případě to propojení & celý ekosystém nemá konkurenci (IMHO).

27

Hardware / Re:Domácí automatizace - hlavice k topení

« kdy: 22. 01. 2019, 09:20:51 »

Zrzka: Díval ses i na to Netatmo? Umí to samé co Tado a je o chlup levnější a neplatí se žádná subskripce...

Díval. Pročítal jsem recenze a našlo se víc lidí, kteří na to nadávali. Proto jsem vybral Tado. Jinak u Tado není subskripce povinná - jenom když chceš Auto Assist. Když nechceš, nic se neplatí a všechno podstatné funguje i tak. Akorát to nepřestane topit když otevřeš okno - to je pro „extra lenochy“

28

Hardware / Re:Domácí automatizace - hlavice k topení

« kdy: 21. 01. 2019, 23:09:05 »

Pak je tady otázka spolehlivosti - čím víc blbin je v systému (web server, rozhraní navíc, servery se sdílením,...), tím víc se toho může podělat. Představ si, že se 23.12. o osmi večer rozhodne topení, že bude ignorovat DHCP a bez spojení s čmoudem se uvede do režimu temperování... Good luck, venku je -13.

Všechno jsou to validní připomínky a beru je. Proto jsem nakonec vybral Tado, které má manuální kontrolu - otáčím termostatem a nastavuju teplotu ručně. Pokud se cokoli pokazí, připojení k netu, domácí síť, ... otočím termostatem na topení stejně jako předtím. A kdyby se podělala hlavice úplně (motorek, nebudou náhradní baterky, ...), zajdu do sklepa a během 15-ti minut tam naházím ty staré a je po experimentu Jsem si vědom toho co všechno se může podělat, proto na to 100% nespoléhám. Prostě si rád hraju a teď zkouším co se dneska nabízí. Jelikož jsem to nekoupil primárně kvůli šetření, zase tolik mě trápit nebude když to vrátím do původního stavu (pokud to vyvede něco co mě nas.re).

29

Hardware / Re:Domácí automatizace - hlavice k topení

« kdy: 21. 01. 2019, 12:42:01 »

Mě by spíš vadilo, že kvůli topení doma musím mít zapnutou polohu na mobilu... to mi příjde šílené... Protože to pak reportuje nejen topenářům, ale všem kdo o to mají zájem...
Prostě polohu zapínat jen když potřebuju navigovat, do toho kde zrovna jsem nikomu nic není.

Pokud automatizaci, tak chci jenom takovou, která si vystačí pouze doma, a neposílá nic na nějaké obskurní weby výrobců a hlavně nepotřebuje předplatné.

Abych to upřesnil - to předplatné je pouze na automatizaci a) otevřených oken, b) polohy telefonů, c) korekce křivky podle předpovědi počasí.

Jakmile člověk nechce předplatné (aka Smart Assist), polohu to nereportuje (když to zakážu v systému, appka neprská), Home/Away se dá nastavit manuálně, ... Všechno ostatní, včetně integrace s HomeKitem, ... funguje i bez předplatného a hlášení polohy. Je to opt-in.

P.S. A není to Smart Assist, ale Auto Assist - https://www.tado.com/gb/thermostat-heating

30

Hardware / Re:Domácí automatizace - hlavice k topení

« kdy: 21. 01. 2019, 11:29:32 »

P.S. Narodila se dcerka, jel jsem pryč a manželka zůstala doma. Jenže jak byla doma, telefon (z nějakého záhadného důvodu) přestal reportovat polohu (víc než 48h) a tak se Tado rozhodlo, že to přepne do Away módu. Jaké překvapení když to druhý den ráno kontroluju. Nejde tam forcnout „Home“ mode (při zapnutém „Smart Assist“ = to předplatné), tak jsem musel urychleně v každé místnosti nastavit vyšší teploty pro „Away“ mód abych nebyl přizabit.

Neboli někdy je to tak chytré, až je to úplně blbé