Server SiFive BigSky SF-2U870 2U je založený na jádře SiFive P870-D, zatím je naintegrovaných 32 jader 256 GB RAM 2 GHz, škálovat lze do 256 jader na čip. O něco podrobnější popis serveru v článku SiFive BigSky Ships the First RISC-V Server. Is the GPU Head Node the Prize? na futurumgroup.com. Asi ani tento čip nebude na úrovni nejlepších 64-bit ARMů a AMD Zenů, ale splňuje RVA23 specifikaci a je podporovaný Ubuntu 26.04 LTS a RHEL 10. V článku je
… více »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ářů.
Ahoj, jednoduchy dotaz na zdatnejsi sitare.
Mama tri switche A,B,C propojene do kruhu, ke switchi A je pripojen router R1, ke switchi C je pripojen router R2.
Udelam dve vlan vlan proti sobe , napr. vlan10, vlan20, vlany se nikde nepotkavaji, tedy neni kruh, na routerech si udelam vlan interface 10 a 20, kazdemu interface nastavit ruzne subnety treba
R1 - vlan10 10.10.10.1/24 , R2 - vlan10 10.10.10.2/24
R1 - vlan20 10.10.20.1/24 , R2 - vlan20 10.10.20.2/24
Takze routery k sobe znaji dve cesty, kdyz pingam z R1 na 10.10.10.2, tak to chvili jde, chvili nejde, kde je problem?
Vadi routerum, ze v arp tabulce vidi pro jednu MAC dva zaznamy IP, tedy oni se nauci MAC pres vlan10 i vlan20 a proto to nemuze fungovat?
Rad bych pouzival oba dva smery, napr. pres vlan10 routoval nejake rozsahy a pres vlan20 jine, aby se tedy provoz rozlozil, je to mozne?
Na switchi je zapnuty spanning tree, konkretne spanning tree per vlan, zda se to funguje v poradku, vidim pro jednotlive vlany porty ve stavu forwarding jine jako blocking (dle path cost, root bridge je nastaven na switchi A, dle priority), pokud odpojit forwardujici port, tak vidim, ze blokovany port se povoli a provoz funguje dal.
Porty na switchi jsou jako trunk = na boxech je vlan interface = pripojene jednim portem , jedna se Mikrotik boxy (5-kova rada routeros).
V arpe routeru vidim naucene MAC adresy protejsku pres oba vlan interface. (tedy napr. pro router A vidim 10.10.10.2 - MAC adres - vlan 10, 10.10.20.2 - MAC adres -vlan20 ).
Mel jsem za to, ze pokud to "zakruhoji" na L3, tak to routerum nebude delat problem, jsem z toho zmateny.
Novy poznatek.
Mikrotik umi pinga na L2 (arp-ping) a zde k timeout vubec nedochazi, takze problem musi byt zrejme na vrst L3 a jeste jsem dosel k zaveru, problem se projevuje jen v jednom smeru, tedy pokud pingam z routeru R1 na R2 tak se objevuji timeout, obracene z R2 na R1 nikoliv, divne.
Kontroloval jsem na switchich MAC tabulky, jestli zde nedochazi k nejakym vypadkum naucenych adres pro vlan 10 a 20, ale nikoliv, adresy jsou tam stale a nikam nepreskakuji, zacinam mit podezreni na router R1 ze je v nejakem "pastavu".
Tiskni
Sdílej: