Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
ip -s -s link show dev eth1 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb qlen 1000 link/ether 00:1d:92:23:6b:fe brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped overrun mcast 747473035 103966270 9 0 0 0 RX errors: length crc frame fifo missed 0 0 0 9 13326 TX: bytes packets errors dropped carrier collsns 4222548359 108744074 0 0 0 0 TX errors: aborted fifo window heartbeat 0 0 0 0Google toho moc neví, někde jsem našel vysvětlení, že se obě strany linky nedokáží domluvit na rychlosti. Tohle jsem vyloučil postupnout výměnou: Routeru (HW i OS), kabelu, switche. Vše je jiné. Jediný problém může být v softu. Proběhla změna OS z Fedora4 na CentOS 5.0. Routování (staticky cca 100 cest), nastavení rozhranní, shaping (htb) zůstalo stejné. Na daný packet loss nemá vliv: vypnuté shapování (tc qdisc del root), vypnutý fw (iptables -F), ani trafic. Začínám mít pocit, že mi tam straší
Kudy ten kabel vedeš? Neni tam nějaký rušení? Píšeš že si vyměnil OS, zkoušel si jiné jádro resp. jinou verzi ovladače?
136k 118k 136k 139k 136k 139k 142k 22k 200k 20k 172k 136k 118k 136k ...Průměr tedy odpovídá. Ale když v jedné sekundě dojde k výpadku, tak v další přijde dvojnásobek dat. Tedy i data z toho výpadku a klient jede rychlostí vyšší než má v HTB. Kolega paří WOW a říkal, že vše co se "během" výpadku stane mu přijde (a od něj odejde) o tu sekundu později. Pak to jede opět normálně. Tomu bych u TCP rozumněl, ale proč přijde naráz dvojnásobek dat je mi také záhadou.
ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: pumbg Wake-on: d Current message level: 0x00000001 (1) Link detected: yes
Zkoušel jsi ten switch restartovat ?
Je vyměněn . Byl tam zcela jiný. Byly tam VLANy, teď je default. Proč si myslíš, že to bude v tom switchi?
Tak Ti mě napadá,jaký trafic jde přes ten router?
cca 10Mb/s. Nadměrná zátěž tu nikde není, vše je měřeno. Ten router se fláká (doufám, že by to load, htop atd ukázal). Počet konektů hluboko pod maximem. Po snížení TCP timetoutu to ještě více kleslo. Ještě doplním, že přímo na tento router není připojeno žádné domácí PC. Jsou na něm servery (nulový trafic, navíc omezeno v HTB) a další routery a až za nimi obyč PC lidí.
A teď mě napadá, co takle odpojit switch od routeru a připojit jen jedno pecko k routeru a zkusit přez něj komunikovat ven ? Víš bez dalších stanic ...
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.
Ano, tohle bude asi jediná možnost. Jenže, po jednom restartu routeru to vydrží třeba dva dny bez jediného vypadlého packetu. Po dalším restartu je loss okamžitý. Odpojit celou síť na dva dny si nemuho dovolit.Co by se stalo, kdybys nic nerestartoval, a rovnou místo toho switche bouchnul PCčko o kterém víš, že je vpořádku a pak začal komunikovat přes ten router ven ? Bylo by to s chybama, které uvádíš ? Tím nechci říct, že by switch, ba ani router nebyly OK, ale pokusil bych se alespoň odstranit doměnku, že si ti dva "nepadly" do oka. Já vím, je to taková šamanština , ale co když ... Jinak , já nevím, mě nic jiného momentálně nenapadá ... Dobrou noc :o)
A nějakej debug to neosvětlí, logování s nejvyšší úrovní?
eth1 Link encap:Ethernet HWaddr 00:10:4B:1C:52:0F inet addr:80.188.227.18 Bcast:80.188.227.23 Mask:255.255.255.248 inet6 addr: fe80::210:4bff:fe1c:520f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:10884428 errors:0 dropped:0 overruns:0 frame:0 TX packets:9087140 errors:0 dropped:0 overruns:0 carrier:129 collisions:2632 txqueuelen:1000 RX bytes:1079902235 (1.0 GiB) TX bytes:1594204219 (1.4 GiB) Interrupt:18 Base address:0xe000pomohlo nastaveni na 10Mbit:
root@nat:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Full Advertised auto-negotiation: Yes Speed: 10Mb/s Duplex: Full Port: MII PHYAD: 24 Transceiver: internal Auto-negotiation: on Current message level: 0x00000001 (1) Link detected: yespak prestali v ciscu a na eth1 ty kolize ... chybu z dmesg si nepamatuju a pravdepodobne se jednalo o jiny problem, jen stejna sitovka ... Ja nevim, s 3comama, mam vzdy nejakou chybu, zatim co s realtekama za 90 korun ne ...
root@nat:~# lspci 00:0a.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78) 00:0c.0 Ethernet controller: 3Com Corporation 3c900B-TPO Etherlink XL [Cyclone] (rev 04) 00:13.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
Procházel jsem i zdrojáky jádra, abych zjistil co to vlastně znamená a nikde nic.Je to deklarované v linux/netdevice.h, resp. linux/if_link.h. Např. ovladač 8139too (drivers/net/8139too.c) mění tento čítač na třech místech. Váš případ bude asi funkce rtl8139_weird_interrupt(), která je volána při přerušení z důvodu chyby (na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce). Počítadlu je přičtena hodnota, která se bere přímo z registru na kartě. Takže bych chybu viděl mezi síťovou kartou a switchem. Ujistit se můžete zapnutím ladění v modulu předefinováním symbolu RTL8139_DEBUG na nenulovou hodnotu (linux-2.6.24.3/drivers/net/8139too.c:129).
na PCI sběrnici, příjmu poškozeného rámce, přetečení fronty v síťovce
Díky. Ano, tohle by tomu odpovídalo, zejména chyba v rámci. To stále více to ukazuje na problém switche. Dám tam ještě lepší a uvidím. Zatím pomáhá restart toho switche (pomůže tak na jeden den) a nastavení 100base TX-HD. Vypadá to, že v něm něco přetéká.
Tiskni
Sdílej: