Odborníci z Penn State University zkoumají způsob ukládání informací na lepicí pásku. Principiálně by podle nich bylo možné kombinací odlepení a zpětného přilepení dosáhnout uložení informace, kterou opětovným odlepením dokážou přečíst. Výhodou je, že způsob uložení i přečtení je čistě mechanický. Zde o tom referují ve volně dostupném článku. Zajímavé bude sledovat zda se jim v rámci výzkumu podaří prokázat použitelnost i v jiné než
… více »Na GitHubu byl publikován reprodukovatelný návod, jak rozchodit Adobe Lightroom CC na Linuxu a Wine. Návod byl vytvořený pomocí AI Claude Code.
Pokud by někdo potřeboval Wayland kompozitor uvnitř počítačové hry Minecraft, aby mohl zobrazovat okna desktopových aplikací přímo v herním prostředí, může sáhnout po Waylandcraftu. Ukázka na YouTube.
Uroš Popović v krátkém článku vysvětluje, co jsou emulátor terminálu, TTY a shell a jaké jsou mezi nimi rozdíly. Jde o první díl seriálu na jeho novém webu Linux Field Guide věnovaném nízkoúrovňové práci s linuxovými systémy.
Byl vydán Debian 13.5, tj. pátá opravná verze Debianu 13 s kódovým názvem Trixie a Debian 12.14, tj. čtrnáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 13 a Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
CiviCRM (Wikipedie) bylo vydáno v nové verzi 6.14.0. Podrobnosti o nových funkcích a opravách najdete na release stránce. CiviCRM je robustní open-source CRM systém navržený speciálně pro neziskové organizace, spolky a občanské iniciativy. Projekt je napsán v jazyce PHP a licencován pod GNU Affero General Public License (AGPLv3). Český překlad má nyní 45 % přeložených řetězců a přibližuje se milníku 50 %. Potřebujeme vaši pomoc, abychom se dostali dál. Pokud máte chuť přispět překladem nebo korekturou, přidejte se na platformu Transifex.
Další lokální zranitelností Linuxu je ssh-keysign-pwn. Uživatel si může přečíst obsah souborů, ke kterým má právo ke čtení pouze root, například soubory s SSH klíči nebo /etc/shadow. V upstreamu již opraveno [oss-security mailing list].
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.
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 0
Google 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ší
Dotazy:
Co všechno může způsobit chyby v RX Error Missed?
Jak může vzniknout PL na samotném routeru?
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?
Se všemi síťovkami se to chovalo stejně (tedy blbě). Sítovka na to nemá vliv. Celkově bylo vyzkoušeno cca 6 různých kombinací síťovek / switchů. Stále stejné (špatné) chování. Tím to nebude. Problém bude v nastavení toho routeru. :- (
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:0xe000
pomohlo 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 ...
A nedochazelo ke zpozdeni a ani vypadavani pingu i OpenVPN jela ok ..
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: