Na YouTube lze zhlédnout nový celovečerní dokumentární film The Story of VS Code | Official Documentary věnovaný Visual Studio Code.
Farid Abdelnour se v příspěvku na blogu rozepsal o novinkám v nejnovější verzi 26.08.0 editoru videa Kdenlive (Wikipedie). Ke stažení také na Flathubu.
Byla vydána nová stabilní verze 8.2 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 152. Přehled novinek i s náhledy v příspěvku na blogu.
Byla vydána nová stabilní verze 4.0 svobodného multiplatformního softwaru pro editování a nahrávání zvukových souborů Audacity (Wikipedie). S rozhraním přepsaným do Qt. Přehled novinek také na YouTube. Ke stažení je oficiální AppImage. Zatím starší verze Audacity lze instalovat také z Flathubu a Snapcraftu.
NVIDIA kupuje Hugging Face za 12,93 miliardy dolarů.
Předobjednat si lze nový jednodeskový počítač Arduino VENTUNO Q s předinstalovaným Ubuntu. S 16 GB LPDDR5 a 64 GB eMMC. Pro lokální LLM, agentní AI, počítačové vidění, robotiku…
Hexpair není nejlepší HEX editor na světě a ani se o to nesnaží. Zato je k dispozici kdykoliv a kdekoliv – všude tam, kde máte svůj Vim. Vznikl jako hobby projekt před pár měsíci a dospěl do stavu, kdy by mohl být užitečný širší komunitě. Přepnout do HEX režimu se dá i uprostřed rozdělané práce: Soubor, který už máte otevřený běžným vim file.md, jedním příkazem přepnete do HEX editoru a dalším příkazem ho můžete vrátit zpět do textu. Kurzor přitom
CERN dlouhodobě používal vlastní sestavení RHEL, ze kterého přešel na CentOS Stream. Federico Vaga a Nikos Tsipinakis ale nyní v přednášce na MiniDebConf Winterthur 2026 popisují plán probíhajícího přechodu na Debian pro řízení akcelerátorů. Důvodem k opuštění CentOS Stream jsou zachování zpětné kompatibility se starším hardwarem, kterou Red Hat narušuje, když tlačí sestavení balíčků pro novější verze architektury (x86-64), a nedostatečné nástroje pro sestavování vlastních balíčků a repozitářů.
UZDoom (Wikipedie), tj. fork GZDoom, byl vydán ve verzi 5.0.0. Videopředstavení na YouTube. Podrobný přehled novinek v Changelogu.
----- -----
| S1 |
-----------
| | |
-- ---- --
|PC| | S2 | |PC|
-- ---- --
| |
-- -- -- --
|PC|--|S3| |S4|--|PC|
-- -- -- --
|
--
|S5|
--
kde S1 - S5 (nie len S5 ale az Sx) su switche a PC su jednotlive PC (alebo viac PC). Cize slovne ma zaujima ci mozem zapojit switch do switchu a ked ano (myslim ze urcite ano) je to mnozstvo obmedzene vnutornou ARP tabulkou toho-ktoreho switchu alebo je tam ine obmedzenie? Plus co sa stane ak tato ARP tabulka nestaci - strati sa paket?
neviete prosim o nejakych clankoch co tuto problematiku blizsie (najlepsie podrobne) riesia? dakujem moc
PS: nebolo by fajnove keby som tu schemu nakreslil bez PRE tagu? he
Teorie říká, že by se nemělo ztrácet nic - pokud má switch svou interní tabulku plnou, tak prostě nejstarší záznamy zahazuje. A když na něj dorazí rámec, pro nějž nemá ve forwardovací tabulce záznam, tak jej prostě pošle všemi porty - zahraje si na hub. To ale samozřejmě vede ke zbytečnému zvyšování zátěže sítě.
To je ovšem jenom teorie, těžko říct, jak se to bude chovat, pokud by ty switche byly (z pohledu velikosti forwardovací tabulky) přetěžovány permanentě. Mohou mít například pomalý procesor a nebudou stíhat tabulku uvolňovat, následně pak třeba nemusí chvilku switchat vůbec, nebo něco zahodí, nebo něco zpozdí, nebo čertvíco, podle typu switche, jeho nálady, síly větru a podobných vlivů. Rozhodně bych se takovému uspořádání vyhnul, protože i když podle teorie by se nemělo stát nic zlého, v praxi bych se spíš obával zcela nepředvídatelného a navíc zcela nediagnostikovatelného chování.
Snad každý switch hodný toho jména má tabulku alespoň na 4K MAC adres, což je až až - tolik aktivních zařízení v jedné logické LAN by bylo přeci jenom trochu moc (například kvůli obrovskému režijnímu ARP provozu).
V praxi máme odzkoušenu podobnou kaskádu cca 50 switchů v cca 6 úrovních pod sebou, do toho nějakých 200 PC. Je to ale asi tak maximum, co jde rozumně provozovat právě s ohledem na režii, diagnostiku a podobně.
Tiskni
Sdílej: