Google oznámil, že Quick Share na Androidu funguje s AirDropem na iOS. Zatím na telefonech Pixel 10. Uživatelé tak mohou snadno přenášet soubory z telefonů s Androidem na iPhony a obráceně.
Byla vydána nová verze 8.5 (8.5.0) skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Přináší řadu novinek a vylepšení (URI Extension, Pipe Operator, Clone With, …). Vydána byla také příručka pro přechod z předchozích verzí.
Evropská komise zahájila tři vyšetřování týkající se cloudových platforem Amazon Web Services (AWS) a Microsoft Azure. Evropská exekutiva, která plní také funkci unijního antimonopolního orgánu, chce mimo jiné určit, zda jsou americké společnosti Microsoft a Amazon v cloudových službách takzvanými gatekeepery, tedy hráči, kteří významně ovlivňují provoz internetu a musí dle nařízení o digitálních trzích (DMA) na společném trhu
… více »Společnost Meta Platforms vyhrála ostře sledovaný spor o akvizici sítě pro sdílení fotografií Instagram a komunikační aplikace WhatsApp. Podle amerického soudu firma jejich převzetím neporušila antimonopolní zákon, protože si tak nemonopolizovala trh sociálních sítí. Žalobu na Metu podala před pěti lety americká Federální obchodní komise (FTC). FTC argumentovala, že Meta, tehdy známá jako Facebook, koupila tyto dvě společnosti v letech 2012 a 2014 proto, aby s nimi nemusela soutěžit.
Home Assistant včera představil svůj nejnovější oficiální hardware: Home Assistant Connect ZBT-2 pro připojení zařízení na sítích Zigbee nebo Thread.
Byla vydána verze 9.1 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a informačním videu.
Byl aktualizován seznam 500 nejvýkonnějších superpočítačů na světě TOP500. Nejvýkonnějším superpočítačem zůstává El Capitan od HPE (Cray) s výkonem 1,809 exaFLOPS. Druhý Frontier má výkon 1,353 exaFLOPS. Třetí Aurora má výkon 1,012 exaFLOPS. Nejvýkonnější superpočítač v Evropě JUPITER Booster s výkonem 1,000 exaFLOPS je na čtvrtém místě. Nejvýkonnější český superpočítač C24 klesl na 192. místo. Karolina, GPU partition klesla na 224. místo a Karolina, CPU partition na 450. místo. Další přehledy a statistiky na stránkách projektu.
Microsoft představil Azure Cobalt 200, tj. svůj vlastní SoC (System-on-Chip) postavený na ARM a optimalizovaný pro cloud.
Co způsobilo včerejší nejhorší výpadek Cloudflare od roku 2019? Nebyl to kybernetický útok. Vše začalo změnou oprávnění v jednom z databázových systémů a pokračovalo vygenerováním problém způsobujícího konfiguračního souboru a jeho distribucí na všechny počítače Cloudflare. Podrobně v příspěvku na blogu Cloudflare.
Byla vydána (Mastodon, 𝕏) první RC verze GIMPu 3.2. Přehled novinek v oznámení o vydání. Podrobně v souboru NEWS na GitLabu.
ifconfig
br0 Link encap:Ethernet HWaddr 00:23:8B:98:2F:9A
inet addr:172.16.129.1 Bcast:172.16.129.255 Mask:255.255.255.0
inet6 addr: fe80::223:8bff:fe98:2f9a/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:36362 errors:0 dropped:0 overruns:0 frame:0
TX packets:38121 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:4056620 (3.8 MiB) TX bytes:47396591 (45.2 MiB)
eth0 Link encap:Ethernet HWaddr 00:23:8B:98:2F:9A
UP BROADCAST PROMISC MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:31 Base address:0x4000
eth2 Link encap:Ethernet HWaddr 00:23:8B:98:2F:98
inet addr:213.211.53.198 Bcast:213.211.53.199 Mask:255.255.255.252
inet6 addr: fe80::223:8bff:fe98:2f98/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:96916640 errors:0 dropped:0 overruns:0 frame:0
TX packets:68004237 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:109039402216 (101.5 GiB) TX bytes:32480288833 (30.2 GiB)
Interrupt:18
eth3 Link encap:Ethernet HWaddr 00:23:8B:98:2F:99
inet addr:172.16.128.1 Bcast:172.16.128.255 Mask:255.255.255.0
inet6 addr: fe80::223:8bff:fe98:2f99/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:486871 errors:0 dropped:0 overruns:0 frame:0
TX packets:395276 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:60348673 (57.5 MiB) TX bytes:469753218 (447.9 MiB)
Interrupt:17
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:24508504 errors:0 dropped:0 overruns:0 frame:0
TX packets:24508504 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:37538738719 (34.9 GiB) TX bytes:37538738719 (34.9 GiB)
tap0 Link encap:Ethernet HWaddr 86:F4:62:14:E6:EF
inet6 addr: fe80::84f4:62ff:fe14:e6ef/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:36373 errors:0 dropped:0 overruns:0 frame:0
TX packets:64846 errors:0 dropped:1053 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:4567613 (4.3 MiB) TX bytes:49051293 (46.7 MiB)
Děkuji za Vaši pomoc.
Zdraví Tom
Stávalo se tak zhruba 1x za hodinu (odpovídalo leasure-time v DHCP), nyní asi 1x za 8 hodin (odpovídá leasure-time nastavenému na 8 hod).
Nemyslíte spíš lease-time?
Ten DHCP server obsluhuje jen jednoho klienta a kromě komunikace s ním se přes eth3 nic neposílá? Nebo celou dobu komunikace funguje správně a ten tx timeout nastane až při odpovědi na DHCP dotaz?
Nemyslíte spíš lease-time?
Ano - máte pravdu, psal jsem to z hlavy.
Ten DHCP server obsluhuje jen jednoho klienta a kromě komunikace s ním se přes eth3 nic neposílá?
DHCP obsluhuje klienty na C(255.255.255.0) lokální síti. Přes eth3 putuje veškerá komunikace sca 200 klientů.
Nebo celou dobu komunikace funguje správně a ten tx timeout nastane až při odpovědi na DHCP dotaz?
DHCP celou dobu funguje správně.
Opravil jsem konfiguraci DHCP a problém se přestal vyskytovat.
Jak jsem psal na serveru je také VPN ve konfiguraci bridge. Do souboru dhcpd.cong jsem přidal subnet pro sít na br0.
subnet 172.16.129.0 netmask 255.255.255.0 {}
Nedokážu říct, kde byl přesně problém. Proč se restartoval ovladače síťové karty, ale v součastné době - po dvou dnech pozorování se zatím problém nevyskytl.
Děkuji za pomoc. Tom
dhcpd nehýbe s konfigurací vašich rozhraní). Ale dneska se všemi těmi offloadingy to nemůžu tvrdit úplně jistě.
Tiskni
Sdílej: