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.
Destination Gateway Flags Refs Use Netif Expire default 10.10.0.1 UGSc 14 103 en1 10.10/24 link#5 UCS 1 0 en1 10.10.0.1 0:60:94:fb:42:c8 UHLW 16 1687 en1 1006 10.10.0.105 127.0.0.1 UHS 0 5 lo0 127 127.0.0.1 UCS 0 0 lo0 127.0.0.1 127.0.0.1 UH 11 2651 lo0 169.254 link#5 UCS 0 0 en1vše je směřováno na bránu, server 10.10.0.1, což je žádoucí. Tam ovšem řeším problém, tam je výpis následující, ale nemohu donutit systém ať ping proběhne na stroje za OpenVPN tunelem, který je vidět v tabulce počítače 10.10.0.1, viz:
Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0 217.112.163.128 0.0.0.0 255.255.255.192 U 0 0 0 wlan0 10.0.0.0 192.168.0.1 255.255.255.0 UG 0 0 0 tun0 10.10.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 217.112.163.129 0.0.0.0 UG 0 0 0 wlan0Na počítači 10.10.0.1 bez problému pingnu na druhou stranu tunelu, což je žádoucí, ale toto neplatí na jiném počítači ze segmentu 10.10.0.0/255.255.255.0, i když dle mého uvažování by neměl být žádný problém, nebo tam něco někdo vidíte? Ping na jiné adresy není problém, ten jede bez problémů. Cílem je vynutit komunikaci ze segmentu 10.10.0.0/255.255.255.0 (jedna síť) se segmentem 10.0.0.0/255.255.255.0 (druhá síť), která je na druhém konci tunelu.
Co na tom klientovi ukáže 'ip route get 10.0.0.1'? Máte povolený forwarding? Ztrácejí se dotazy nebo odpovědi? Kde přesně ten paket mizí?
Výpisy příkazu route jsou dost nepřehledné (a někdy i neúplné). Ukazujte raději výpisy 'ip route show'.
23:54:56.094284 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 0 23:54:57.095105 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 1 23:54:58.094966 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 2 23:54:59.096577 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 3 23:55:00.097595 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 4 23:55:01.099313 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 5 23:55:02.100559 IP 10.10.0.105 > 10.0.0.100: icmp 64: echo request seq 6 23:55:08.665637 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 0 23:55:08.666047 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 0 23:55:09.666950 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 1 23:55:09.667277 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 1 23:55:10.667581 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 2 23:55:10.667974 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 2 23:55:11.670649 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 3 23:55:11.670981 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 3 23:55:12.670154 IP 10.10.0.105 > 10.10.0.1: icmp 64: echo request seq 4 23:55:12.670549 IP 10.10.0.1 > 10.10.0.105: icmp 64: echo reply seq 4 23:55:23.710750 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 0 23:55:23.726170 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 0 23:55:24.711886 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 1 23:55:24.727848 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 1 23:55:25.712656 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 2 23:55:25.724074 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 2 23:55:26.713146 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 3 23:55:26.727620 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 3 23:55:27.715368 IP 10.10.0.105 > abicko.abclinuxu.cz: icmp 64: echo request seq 4 23:55:27.730529 IP abicko.abclinuxu.cz > 10.10.0.105: icmp 64: echo reply seq 4 27 packets captured 27 packets received by filter 0 packets dropped by kernel
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
ip route get <ip> se da nahradit route get <ip>
64 bytes from 10.10.0.1: icmp_seq=1 ttl=64 time=3.111 ms 64 bytes from 10.10.0.1: icmp_seq=2 ttl=64 time=3.015 ms 64 bytes from 10.10.0.1: icmp_seq=3 ttl=64 time=4.265 ms 64 bytes from 10.10.0.1: icmp_seq=4 ttl=64 time=3.110 ms 64 bytes from 10.10.0.1: icmp_seq=5 ttl=64 time=4.154 ms 64 bytes from 10.10.0.1: icmp_seq=6 ttl=64 time=3.053 ms 64 bytes from 10.10.0.1: icmp_seq=7 ttl=64 time=3.147 msa obráceně:
64 bytes from 10.10.0.105: icmp_seq=0 ttl=64 time=2.0 ms 64 bytes from 10.10.0.105: icmp_seq=1 ttl=64 time=173.4 ms 64 bytes from 10.10.0.105: icmp_seq=2 ttl=64 time=196.6 ms 64 bytes from 10.10.0.105: icmp_seq=3 ttl=64 time=16.4 ms 64 bytes from 10.10.0.105: icmp_seq=4 ttl=64 time=40.8 ms 64 bytes from 10.10.0.105: icmp_seq=5 ttl=64 time=64.0 ms 64 bytes from 10.10.0.105: icmp_seq=6 ttl=64 time=88.0 ms 64 bytes from 10.10.0.105: icmp_seq=7 ttl=64 time=112.4 msi toto mě lehce mate, sice je mezi tím AP, ale to by snad na úrovni TCP/IP mělo být jen průchozí, žádný filtr ani omezení AP nemá aktivováno.
Tiskni
Sdílej:
