Byly zpracovány a na YouTube zveřejněny videozáznamy jednotlivých přednášek z letošního Installfestu.
Během akce Arduino Days 2026 byl publikován Arduino Open Source Report 2025 (pdf) a oznámeno 7 nových produktů kompatibilních s deskou UNO Q (Arduino USB-C Power Supply, USB-C Cable, USB-C Hub, UNO Media Carrier, UNO Breakout Carrier, Bug Hopper, Modulino LED Matrix).
Google v pátek spustil v Česku Vyhledávání Live. Tato novinka umožňuje lidem vést plynulou konverzaci s vyhledávačem v češtině. A to prostřednictvím hlasu, nebo prostřednictvím toho, na co ukážou svým fotoaparátem či kamerou v mobilu. Rozšíření této multimodální funkce je možné díky nasazení Gemini 3.1 Flash Live, nového hlasového a audio modelu, který je od základu vícejazyčný, takže umožňuje lidem po celém světě mluvit na vyhledávač přirozeně a v jazyce, který je jim nejbližší.
Jsongrep je open-source nástroj, který efektivně prohledává JSON dokumenty (editovat je neumí). Kompiluje regulérní jazyk dotazu do podoby deterministického konečného automatu (DFA), díky čemuž prochází strom JSON dokumentu pouze jednou a je v tom tedy rychlejší než jiné nástroje jako jsou například jq, JMESPath nebo jql. Jsongrep je napsaný v programovacím jazyce Rust, zdrojový kód je dostupný na GitHubu.
O víkendu probíhá v Praze na Karlově náměstí 13 konference Installfest 2026. Na programu je celá řada zajímavých přednášek a workshopů. Vstup na konferenci je zcela zdarma, bez nutnosti registrace. Přednášky lze sledovat i online na YouTube.
Mozilla a společnost Mila oznámily strategické partnerství za účelem rozvoje open source a suverénní AI. Cílem je ukázat, že open source AI může konkurovat uzavřeným systémům. Obě organizace chtějí posílit technologickou suverenitu a snížit závislost na hrstce velkých technologických firem.
Adam Rice předvedl, že pomocí DNS lze distribuovat a spustit kompletní hru DOOM. Rozdělil WAD soubory a binárky do téměř 2000 DNS záznamů v Cloudflare zóně (jeden TXT záznam v DNS může nést okolo 2000 znaků textu). Ty pak stáhl PowerShellem, dekomprimoval a spustil přímo v paměti počítače bez nutnosti zápisu na disk, což prakticky dokazuje, že DNS může sloužit jako distribuované úložiště dat a možný kanál pro načítání kódu. Repozitář projektu je na GitHubu.
Dnes a zítra probíhají Arduino Days 2026. Na programu je řada zajímavých přednášek. Sledovat je lze od 17:00 na YouTube. Zúčastnit se lze i lokálních akcí. Dnes v Poličce v městské knihovně a zítra v Praze na Matfyzu.
Byla vydána beta verze Ubuntu 26.04 LTS s kódovým názvem Resolute Raccoon. Přehled novinek v poznámkách k vydání. Dle plánu by Ubuntu 26.04 LTS mělo vyjít 23. dubna 2026.
Byla vydána aktualizována Příručka pro začínající wikipedisty a wikipedistky (pdf).
PING google.com (172.217.23.206): 56 data bytes 64 bytes from 172.217.23.206: icmp_seq=0 ttl=119 time=16.836 ms 64 bytes from 172.217.23.206: icmp_seq=1 ttl=119 time=15.337 ms 64 bytes from 172.217.23.206: icmp_seq=2 ttl=119 time=16.177 ms 64 bytes from 172.217.23.206: icmp_seq=3 ttl=119 time=15.666 ms 64 bytes from 172.217.23.206: icmp_seq=4 ttl=119 time=15.455 ms --- google.com ping statistics --- 5 packets transmitted, 5 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 15.337/15.894/16.836/0.552 msAno je to urcite zlepsenie, ale pocital som, ze na optike to bude omnoho lepsie. Meranie som vykonal na GW PFSense. Mam to nainstalovane v KVM, tak dufam, ze to spozdenie nebude tam. Sused ma nejakeho miestneho ISP a ping ma 4-5ms. Kde sa moze ten ping spozdovat, moze byt problem ISP (telekom) ?
PING 172.217.23.206 (172.217.23.206) 56(84) bytes of data. 64 bytes from 172.217.23.206: icmp_seq=1 ttl=55 time=10.2 ms 64 bytes from 172.217.23.206: icmp_seq=2 ttl=55 time=9.93 ms 64 bytes from 172.217.23.206: icmp_seq=3 ttl=55 time=10.3 ms 64 bytes from 172.217.23.206: icmp_seq=4 ttl=55 time=10.1 msAno, ISP může hrát velkou roli, a pokud je u vás telekom, to co u nás O2, pak bych se tomu moc nedivil.
zakaznik------opika-------wifi_bod------vzduch------wifi_bod----optika-----miestny_isp ----optika-energotel-----Chcel by som vediet ako pristupujem ja cez telekom na internet
traceroute 213.81.232.205 traceroute to 213.81.232.205 (213.81.232.205), 30 hops max, 60 byte packets 1 pfsense.local (192.168.1.1) 0.496 ms 0.414 ms 0.363 ms 2 st-static-bckb-205.213-81-232.telecom.sk (213.81.232.205) 4.436 ms 4.383 ms 4.334 msMyslim, ze problem bude infrastruktura telekomu
4ms na první hop je docela dost - ale to je i těch ~0.4ms na localhostu. Na druhou stranu, ani těch 16ms výše není nic hrozného, pro většinu praktických aplikací ani 50ms RTT nepředstavuje problém, a to včetně hlasové nebo video komunikace (pokud tam není moc velký rozptyl nebo nezanedbatelná ztrátovost).
Jsou samozřejmě výjimky, dřív jsem třeba občas pouštěl vzdáleně "git gui" na počítači v práci pomocí X11 tunelovaného v ssh a fungovalo to naprosto krásně, dokud jsem se nemusel dočasně přepnout na jinou VPN gateway a RTT nestoupl nad 25ms, pak už to moc nešlo. Většina běžně používaných aplikací ale takhle citlivá na latence není.
ping -c3 -4 www.six.sk PING pmc.cvt.stuba.sk (147.175.1.70) 56(84) bytes of data. 64 bytes from pmc.cvt.stuba.sk (147.175.1.70): icmp_seq=1 ttl=58 time=2.25 ms 64 bytes from pmc.cvt.stuba.sk (147.175.1.70): icmp_seq=2 ttl=58 time=2.81 ms 64 bytes from pmc.cvt.stuba.sk (147.175.1.70): icmp_seq=3 ttl=58 time=1.92 msPorovnavat ping na google zo susedom co ma ineho ISP, sa sice tiez da, ale kazdy mozte ist do uplne ineho datacentra. U mna je google.com napr. v prahe, tiez 15-16ms.
traceroute to 172.217.23.196 (172.217.23.196), 30 hops max, 60 byte packets 1 home (10.0.0.254) 0.523 ms 0.505 ms 0.490 ms 2 62.197.224.1 (62.197.224.1) 4.319 ms 4.267 ms 4.284 ms 3 195.168.66.113 (195.168.66.113) 6.151 ms 6.013 ms 6.326 ms 4 62.168.99.37 (62.168.99.37) 7.422 ms 7.443 ms 7.309 ms 5 hu-0-2-0-0.gwup.dc.ba.gts.sk (62.168.99.154) 5.754 ms 4.963 ms 4.890 ms 6 brat-b2-link.ip.twelve99.net (62.115.148.138) 5.001 ms 5.219 ms 5.342 ms 7 win-bb4-link.ip.twelve99.net (62.115.121.222) 10.636 ms 6.040 ms win-bb3-link.ip.twelve99.net (62.115.121.218) 12.677 ms 8 win-b2-link.ip.twelve99.net (62.115.114.185) 12.469 ms win-b2-link.ip.twelve99.net (62.115.114.183) 9.150 ms win-b2-link.ip.twelve99.net (62.115.114.185) 13.399 ms 9 google-ic319725-win-b2.ip.twelve99-cust.net (62.115.151.23) 19.402 ms 15.953 ms 19.324 ms 10 108.170.252.19 (108.170.252.19) 19.954 ms 108.170.251.144 (108.170.251.144) 26.926 ms 108.170.252.19 (108.170.252.19) 20.013 ms 11 209.85.253.1 (209.85.253.1) 20.115 ms 209.85.241.131 (209.85.241.131) 15.808 ms 50.280 ms 12 209.85.247.190 (209.85.247.190) 20.018 ms 108.170.245.33 (108.170.245.33) 20.223 ms 108.170.245.49 (108.170.245.49) 20.632 ms 13 108.170.245.33 (108.170.245.33) 20.248 ms 108.170.238.161 (108.170.238.161) 15.852 ms 15.758 ms 14 prg03s05-in-f196.1e100.net (172.217.23.196) 16.795 ms 108.170.238.161 (108.170.238.161) 19.213 ms prg03s05-in-f4.1e100.net (172.217.23.196) 15.764 ms
PING pmc.cvt.stuba.sk (147.175.1.70): 56 data bytes 64 bytes from 147.175.1.70: icmp_seq=0 ttl=59 time=12.171 ms 64 bytes from 147.175.1.70: icmp_seq=1 ttl=59 time=11.307 ms 64 bytes from 147.175.1.70: icmp_seq=2 ttl=59 time=11.201 ms --- pmc.cvt.stuba.sk ping statistics --- 3 packets transmitted, 3 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 11.201/11.560/12.171/0.435 msJa som pod 10ms este nikdy nesiel
PING pmc.cvt.stuba.sk (147.175.1.70) 56(84) bytes of data. 64 bytes from pmc.cvt.stuba.sk (147.175.1.70): icmp_seq=1 ttl=59 time=2.37 ms 64 bytes from pmc.cvt.stuba.sk (147.175.1.70): icmp_seq=2 ttl=59 time=2.33 ms --- pmc.cvt.stuba.sk ping statistics --- 3 packets transmitted, 2 received, 33% packet loss, time 2002ms rtt min/avg/max/mdev = 2.331/2.354/2.378/0.053 ms PING 172.217.23.196 (172.217.23.196) 56(84) bytes of data. 64 bytes from 172.217.23.196: icmp_seq=1 ttl=119 time=6.92 ms 64 bytes from 172.217.23.196: icmp_seq=2 ttl=119 time=6.68 ms 64 bytes from 172.217.23.196: icmp_seq=3 ttl=119 time=6.72 ms --- 172.217.23.196 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2003ms rtt min/avg/max/mdev = 6.689/6.780/6.927/0.124 ms PING 147.175.1.70 (147.175.1.70) 56(84) bytes of data. 64 bytes from 147.175.1.70: icmp_seq=1 ttl=59 time=2.50 ms 64 bytes from 147.175.1.70: icmp_seq=2 ttl=59 time=2.40 ms --- 147.175.1.70 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 2.402/2.451/2.500/0.049 ms
To záleží na spoustě faktorů - kolik je hopů, jak vypadají a jak jsou zatížené… Prostě jsou mezi jednotlivými nabídkami připojení dost velké rozdíly a někteří očividně spoléhají na to, že většinu potenciálních zákazníků zajímá jen nominální "rychlost" - a, po pravdě, většinu dost možná nic jiného ani zajímat nemusí.
Ale pre dobro na srdci by ma potesil nizsi ping
Na "dobro na srdci" se vykašlete; pokud při tom, co děláte nebo chcete dělat, nepociťujete, že by vás ta latence nějak omezovala, není důvod to řešit. Jak už bylo řečeno, 16ms s minimálním rozptylem opravdu není nic, z čeho by bylo potřeba si dělat těžkou hlavu. Ale jestli se chcete mermomocí užírat, tak ať to stojí za to… takhle to vypadá u nás ve vidlákově:
--- 172.217.23.206 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9014ms rtt min/avg/max/mdev = 1.540/1.591/1.673/0.043 ms
:-)
$ ping -4 -c 50 -q google.com PING (172.217.23.238) 56(84) bytes of data. --- ping statistics --- 50 packets transmitted, 50 received, 0% packet loss, time 49062ms rtt min/avg/max/mdev = 2.348/3.619/9.658/1.548 msPro tazatele: google hostuje "skoro všude", má více center, stejně jako třeba Amazon. Ani internet není něco jako "hmotný bod" a cesta skrze jedno A.S. (ISP) zabere nějaký nenulový čas.
Tiskni
Sdílej: