Singularity (YouTube) je nejnovější otevřený film od Blender Studia. Jedná se o jejich první 4K HDR film.
Vyšla hra Život Není Krásný: Poslední Exekuce (Steam, ProtonDB). Kreslená point & click adventura ze staré školy plná černého humoru a nekorektního násilí. Vžijte se do role zpustlého exekutora Vladimíra Brehowského a projděte s ním jeho poslední pracovní den. Hra volně navazuje na sérii Život Není Krásný.
Společnost Red Hat představila Fedora Hummingbird, tj. linuxovou distribuci s nativním kontejnerovým designem určenou pro vývojáře využívající AI agenty.
Hru The Legend of Zelda: Twilight Princess od společnosti Nintendo si lze nově díky projektu Dusklight (původně Dusk) a reverznímu inženýrství zahrát i na počítačích a mobilních zařízeních. Vyžadována je kopie původní hry (textury, modely, hudba, zvukové efekty, …). Ukázka na YouTube. Projekt byl zahájen v srpnu 2020.
Byla vydána nová major verze 29.0 programovacího jazyka Erlang (Wikipedie) a související platformy OTP (Open Telecom Platform, Wikipedie). Detailní přehled novinek na GitHubu.
Po zranitelnostech Copy Fail a Dirty Frag přichází zranitelnost Fragnesia. Další lokální eskalace práv na Linuxu. Zatím v upstreamu neopravena. Přiřazeno ji bylo CVE-2026-46300.
Sovereign Tech Agency (Wikipedie) prostřednictvím svého fondu Sovereign Tech Fund podpoří KDE částkou 1 285 200 eur.
Google na včerejší akci The Android Show | I/O Edition 2026 (YouTube) představil celou řadu novinek: Gemini Intelligence, notebooky Googlebook, novou generaci Android Auto, …
Evropská komise by do léta mohla předložit návrh normy omezující používání sociálních sítí dětmi v zájmu jejich bezpečí na internetu. Prohlásila to včera předsedkyně EK Ursula von der Leyenová, podle níž řada zemí Evropské unie volá po zavedení věkové hranice pro sociální sítě. EU částečně řeší bezpečnost dětí v digitálním prostředí v již platném nařízení o digitálních službách (DSA), podle německé političky to však není dostatečné a
… více »Multiplatformní open source aplikace scrcpy (Wikipedie) pro zrcadlení připojeného zařízení se systémem Android na desktopu a umožňující ovládání tohoto zařízení z desktopu, byla vydána v nové verzi 4.0.
V posledních dnech jsem zaznamenal trochu problémy s připojením k Internetu. Situace je dost výkyvová, někdy funguje celkem normálně, jindy skoro vůbec. Hlavně je problém s odezvou (ping).
Dříve bývala odezva více méně standardní, kolem 10 ms na Seznam:
PING seznam.cz (77.75.76.3) 56(84) bytes of data. 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=1 ttl=247 time=10.7 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=2 ttl=247 time=11.7 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=3 ttl=247 time=11.3 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=247 time=10.2 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=5 ttl=247 time=10.2 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=6 ttl=247 time=10.6 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=7 ttl=247 time=10.5 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=8 ttl=247 time=10.5 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=9 ttl=247 time=9.74 ms ^C --- seznam.cz ping statistics --- 9 packets transmitted, 9 received, 0% packet loss, time 8011ms rtt min/avg/max/mdev = 9.742/10.649/11.731/0.572 ms
Teď je to ale výrazně horší a i ztráta narostla na 20%:
PING seznam.cz (77.75.76.3) 56(84) bytes of data. 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=1 ttl=247 time=5517 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=2 ttl=247 time=5555 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=3 ttl=247 time=5597 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=247 time=5563 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=7 ttl=247 time=3572 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=8 ttl=247 time=3323 ms ^C64 bytes from www.seznam.cz (77.75.76.3): icmp_req=9 ttl=247 time=3325 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=247 time=3303 ms --- seznam.cz ping statistics --- 10 packets transmitted, 8 received, 20% packet loss, time 58679ms rtt min/avg/max/mdev = 3303.180/4469.824/5597.952/1091.669 ms, pipe 6
Svoje dojmy jsem si potvrdil i při pohledu na graf Sixxs (můj poskytovatel IPv6 tunelu). V posledních třech dnech je jasně patrné zhoršení parametrů:


Nechci nikoho neprávem osočovat, ale musím říct, že když to byl ještě Volný, takové problémy nebyly.
Když se přepnu (ip route replace default via 192.168.1.20 dev eth0) na druhou bránu a tím i jiného ISP (zatím je ve fázi testování a snad se brzy překlopí do fáze normálního používání) dostáváme se najednou na úplně jiná čísla:
PING seznam.cz (77.75.76.3): 56 data bytes 64 bytes from 77.75.76.3: seq=0 ttl=247 time=3.695 ms 64 bytes from 77.75.76.3: seq=1 ttl=247 time=3.100 ms 64 bytes from 77.75.76.3: seq=2 ttl=247 time=3.607 ms … 64 bytes from 77.75.76.3: seq=6 ttl=247 time=3.696 ms 64 bytes from 77.75.76.3: seq=7 ttl=247 time=2.912 ms 64 bytes from 77.75.76.3: seq=8 ttl=247 time=3.179 ms 64 bytes from 77.75.76.3: seq=9 ttl=247 time=2.768 ms 64 bytes from 77.75.76.3: seq=10 ttl=247 time=2.882 ms 64 bytes from 77.75.76.3: seq=11 ttl=247 time=2.958 ms --- seznam.cz ping statistics --- 12 packets transmitted, 12 packets received, 0% packet loss round-trip min/avg/max = 2.768/3.227/4.054 ms
Tři milisekundy místo pěti vteřin a 0% ztráta místo 20%, to už je celkem znát.
Tiskni
Sdílej:
# tracepath seznam.cz
1: 192.168.1.4 0.090ms pmtu 1500
1: no reply
2: no reply
2: lo0-bras1-prg1-plus.ctc.prg.vol.cz 4735.237ms
2: lo0-bras1-prg1-plus.ctc.prg.vol.cz 5657.596ms
5: no reply
4: ge1-2.bb1.prg.vol.cz 6222.796ms asymm 5
7: no reply
5: ge4-2.tr3.prg.vol.cz 6226.325ms
6: 82.119.252.141 5812.170ms asymm 7
6: 82.119.252.141 5563.078ms asymm 7
11: no reply
12: no reply
13: no reply
14: no reply
15: no reply
16: no reply
17: no reply
18: no reply
19: no reply
20: no reply
21: no reply
22: no reply
23: no reply
24: no reply
25: no reply
26: no reply
27: no reply
28: no reply
29: no reply
30: no reply
31: no reply
Too many hops: pmtu 1500
Resume: pmtu 1500
Ping z ADSL modemu na nejbližší bránu Telekomu/O2/Volného:
# ping 88.146.111.37 PING 88.146.111.37 (88.146.111.37): 56 data bytes 64 bytes from 88.146.111.37: icmp_seq=0 ttl=255 time=5120.0 ms 64 bytes from 88.146.111.37: icmp_seq=1 ttl=255 time=5580.0 ms 64 bytes from 88.146.111.37: icmp_seq=4 ttl=255 time=5910.0 ms 64 bytes from 88.146.111.37: icmp_seq=5 ttl=255 time=5970.0 ms --- 88.146.111.37 ping statistics --- 12 packets transmitted, 4 packets received, 66% packet loss round-trip min/avg/max = 5120.0/5645.0/5970.0 ms
DNS 194.228.41.113 a 194.228.2.1
ping www.seznam.cz PING www.seznam.cz (77.75.76.3) 56(84) bytes of data. 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=1 ttl=250 time=15.6 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=2 ttl=250 time=14.6 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=3 ttl=250 time=14.8 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=4 ttl=250 time=15.3 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=5 ttl=250 time=15.5 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=6 ttl=250 time=14.8 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=7 ttl=250 time=17.9 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=8 ttl=250 time=15.8 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=9 ttl=250 time=15.0 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_req=10 ttl=250 time=15.2 ms ^C --- www.seznam.cz ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9013ms rtt min/avg/max/mdev = 14.613/15.496/17.993/0.917 mszhruba je to stále stejné tak jak předtím
PING seznam.cz (77.75.76.3) 56(84) bytes of data. 64 bytes from www.seznam.cz (77.75.76.3): icmp_seq=1 ttl=251 time=0.730 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_seq=2 ttl=251 time=0.783 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_seq=3 ttl=251 time=0.847 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_seq=4 ttl=251 time=0.586 ms 64 bytes from www.seznam.cz (77.75.76.3): icmp_seq=5 ttl=251 time=0.749 ms --- seznam.cz ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4006ms rtt min/avg/max/mdev = 0.586/0.739/0.847/0.086 msAle z domova 9 ms.
. Nebo se zvýšil počet adsl uživatelů na daném kabelu. Díky přeslechům se pak jednotlivé přípojky ovlivňují a rychlost se rapidně snižuje. Nebo odešel port na kartě v DSLAMu. Stát se toho mohlo hodně. Když vyloučíte problém u sebe, pak nic jiného, než volat servis, nezbude. Ty odezvy jsou hrozně velké a pokud je tam i ztrátovost, tipoval bych to na port nebo kyslíkovej kabel
.