Stanislav Fort, vedoucí vědecký pracovník z Vlčkovy 'kyberbezpečnostní' firmy AISLE, zkoumal dopady Anthropic Mythos (nový AI model od Anthropicu zaměřený na hledání chyb, který před nedávnem vyplašil celý svět) a předvedl, že schopnosti umělé inteligence nejsou lineárně závislé na velikosti nebo ceně modelu a dokázal, že i některé otevřené modely zvládly v řadě testů odhalit ve zdrojových kódech stejné chyby jako Mythos (například FreeBSD CVE-2026-4747) a to s výrazně nižšími provozními náklady.
Federální návrh zákona H.R.8250 'Parents Decide Act', 13. dubna předložený demokratem Joshem Gottheimerem a podpořený republikánkou Elise Stefanik coby spolupředkladatelkou (cosponsor), by v případě svého schválení nařizoval všem výrobcům operačních systémů při nastavování zařízení ověřovat věk uživatelů a při používání poskytovat tento věkový údaj aplikacím třetích stran. Hlavní rozdíl oproti kalifornskému zákonu AB 1043 a kolorádskému SB26-051 je ten, že federální návrh by platil rovnou pro celé USA.
Qwen (čínská firma Alibaba Cloud) představila novou verzi svého modelu, Qwen3.6‑35B‑A3B. Jedná se o multimodální MoE model s 35 miliardami parametrů (3B aktivních), nativní kontextovou délkou až 262 144 tokenů, 'silným multimodálním vnímáním a schopností uvažování' a 'výjimečnou schopností agentického kódování, která se může měřit s mnohem rozsáhlejšími modely'. Model a dokumentace jsou volně dostupné na Hugging Face, případně na čínském Modelscope. Návod na spuštění je už i na Unsloth.
Sniffnet, tj. multiplatformní (Windows, macOS a Linux) open source grafická aplikace pro sledování internetového provozu, byl vydán ve verzi 1.5. V přehledu novinek je vypíchnuta identifikace aplikací komunikujících po síti.
V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 15.0 (Mastodon). Forgejo je fork Gitei.
Současně se SUSECON 2026 proběhne příští čtvrtek v Praze také komunitní Open Developer Summit (ODS) zaměřený na open source a openSUSE. Akce se koná ve čtvrtek 23. 4. (poslední den SUSECONu) v Hilton Prague (místnost Berlin 3) a je zcela zdarma, bez nutnosti registrace na SUSECON. Na programu jsou témata jako automatizace (AutoYaST), DevOps, AI v terminálu, bezpečnost, RISC-V nebo image-based systémy. Všichni jste srdečně zváni.
Český úřad zeměměřický a katastrální zavedl u anonymního nahlížení do katastru nemovitostí novou CAPTCHA ve formě mapové puzzle: nepřihlášení uživatelé musí nově správně otočit devět dlaždic v 3x3 poli tak, aby dohromady daly souvislý obrázek výseče reálné mapy, přičemž na to mají pouze jeden časově omezený pokus. Test je podle uživatelů i odborníků příliš obtížný a na sociálních sítích pochopitelně schytává zaslouženou kritiku a
… více »Byla vydána verze 1.95.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Mozilla prostřednictvím své dceřiné společnosti MZLA Technologies Corporation představila open-source AI klienta Thunderbolt. Primárně je určený pro firemní nasazení.
Firma Cal.com oznámila, že přesouvá svůj produkční kód z otevřeného do uzavřeného repozitáře z důvodu bezpečnostního rizika umělé inteligence, která prý dokáže vyhledávat a zneužívat zranitelnosti rychleji, než by je jejich vývojářský tým stíhal opravovat. Zároveň zveřejnila samostatnou, open-source verzi Cal.diy pod licencí MIT, ovšem bez řady původních funkcí. O tom, zda je toto opatření rozumné, existují pochyby. … více »
Datové FC routery se v sítích SAN používají na překlad jednoho protokolu na jiný. Může se jednat o překlad z protokolu SCSI na FC nebo například iSCSI na FC. Jedná se o relativně levnou (v porovnáním s výměnou pole) metodu, jak poskytnout koncovým klientům například iSCSI konektivitu, pokud současné diskové pole iSCSI nezvládá. Případně vám umožní připojit do SAN starší páskovou mechaniku, která zvládá jen SCSI protokol. Často bývají routery také označovány slovem „gateway“ nebo „bridge“.
Velice významnou roli hraje FC router při tvorbě odolných řešení, například umožní tunelovat FC protokol prostřednictvím jiného typu sítě, třeba sítě typu IP. V takovém případě se bude jednat o router podporující protokol iFCP (Internet Fibre Channel Protocol) a FCP (Fibre Channel Protocol). V takovém řešení budete mít v každém datovém centru vlastní FC SAN a obě tyto SAN budou propojeny právě prostřednictvím tohoto routeru a protokolu iFCP nebo FCIP.
Protokol iFCP, jak již název napovídá, zapouzdřuje FC rámce a přenáší je na druhou stranu, a to prostřednictvím TCP spojení. Umožňuje propojení SAN sítí na libovolnou vzdálenost prostřednictvím běžné IP WAN sítě. Další protokol umožňující propojení SAN sítí prostřednictvím sítí IP je protokol FCIP (Fibre Channel over IP).
SAN router Brocade 7500E
Teď se možná ptáte, k čemu existují dva různé protokoly se stejným účelem, totiž propojit dvě sítě SAN prostřednictvím sítě IP. Zásadní rozdíl mezi těmito protokoly je v tom, jakým způsobem propojují. V případě protokolu FCIP se jedná o tunel, který propojuje dvě vzdálené sítě do jednoho společného celku – jedné fabric, a to se všemi pozitivy i negativy. V jednom FC ostrovu (FC island) je tak vidět veškerý traffic a zařízení, která spadají do druhého FC ostrovu. Z pohledu FC switchů jsou tyto propojeny běžným portem typu inter-switch link (ISL). Zařízení, které takto propojuje sítě, se také nazývá Fibre Channel extender. Každý Fibre Channel extender pracující s FCIP má tzv. buffer (občas v literatuře nazývané taky buffer credits), nicméně zabývat se buffer credits by bylo až příliš zdlouhavé, proto si to necháme snad na samostatný článek – vyšší dívčí. Důležité je, že čím více buffer credits, tím lépe. V závislosti na jejich množství bude vaše SAN rychlejší a bude fungovat na větší vzdálenost (s vyšší latencí).
Na druhou stranu protokol iFCP umožňuje zařízením v dvou různých SAN (jedná se již o dvě různé SAN, nikoli o jednu rozsáhlou SAN propojenou tunelem) komunikovat. Všechno, co se děje v jedné SAN, se nepřenáší do druhé, pouze provoz určený pro zařízení v druhé SAN bude přenesen po iFCP propojení. Tedy na rozdíl od FCIP, iFCP nepřenáší například chyby. Pokud se něco stane v SAN propojené pomocí FCIP, ochromí to oba FC ostrovy. Pokud se něco podobného stane ve dvou SAN, které jsou propojeny pomocí iFCP, chyba zůstane izolována v SAN, kde k chybě došlo. U iFCP dochází k namapování Fibre Channel adres na IP adresy a poslání TCP/IP paketu na druhou stranu. Pro více informací o iSCSI, iFCP a FCIP doporučuji nastudovat knihu IP SANs: a guide to iSCSI, iFCP, and FCIP protocols for storage area networks nebo si počkat na některý z dalších dílů.
Stejně tak při iFCP nebude docházet k volení (election) řídícího switche (Principal Switch – PS) při výpadku IP konektivity mezi těmito dvěma SAN a podobně. iFCP síť se tedy z celkového pohledu bude chovat na stejné konektivitě více stabilně.
V minulém díle jsme si řekli, že existuje nějaký FC-SW protokol, stejně jako ISL – inter-switch link, který propojuje jednotlivé switche, ale jsou i další druhy portů u fabric switchů? Když se tak ptám, tak asi ano… a to následující (z důvodu jednoduchosti vynecháme všechny proprietární rozšíření od společností Cisco, Brocase, QLogic a dalších).
| Název portu | Určení portu |
| N_port | Node port – port používaný k připojení koncových uzlů, jako jsou disková pole nebo klienty na straně koncových zařízení |
| F_port | Fabric port – port používaný k připojení koncových uzlů jako jsou disková pole nebo klienty na straně switche |
| E_port | ISL – Inter-Connect Link – port používaný k propojení dvou různých switchů v rámci jedné fabric |
| EX_port | port používaný k propojení routerů a switchů, na straně routeru se tváří jako EX_port, na straně switche jako E_port |
Ve chvíli, kdy je switch připojen do sítě, je mu přiděleno tzv. Domain_ID. V každé FC-SW síti se volí řídící switch (Principal Switch – PS), samotný proces je podobný k tomu, jak se volí root bridge switch v protokolu Spanning Tree, poté následuje distribuce Domain_ID. Předtím, než mohou jednotlivé switche komunikovat mezi sebou, se každý z nich zkonfiguruje, aby zjistil, co má kde připojeno na kterých N_portech. Switch přiřadí FCID ke každému připojenému uzlu, které je odvozeno od Domain_ID, Area_ID a WWN připojeného zařízení.
Proces probíhá zhruba následovně:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
E_portu dojde k přenesení BF rámce (výjimka: BF rámce se nezasílají na E_porty, na kterých byly obdrženy – zabraňuje se tak smyčkám)PS_Priority, PS_Name a seznam Domain_ID.PS_Priority a PS_Name a vybere se vítěz, nižší číslo vyhrává.Po zvolení PS switche tento začne distribuci seznamu Domain_ID.
Příště si představíme používané topologie v FC sítích, jako jsou dvojitý switch (Dual switch), Kruh switchů (Loop of switches), křížová síť (Meshed fabric), hvězda (Star) a jádro-okraj (Core-edge). Také si povíme o zónách a vysvětlíme si rozdíl mezi soft a hard zónami.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Pouziva google ve sve infrastrukture take tyto prvky? (diskova pole, FC switche...), ja dokazi zajistit, na tolika pocitacich, ze ty data ten konkretni stroj zrovna ma? Nekde jsem cetl, ze servery google jsou "jen" hromada plecen PIII apod, co je na tom pravdy?
Ale z veřejně dostupných informací (např. přednášky lidí z Googlu) je to asi tak: v měřítku systémů Googlu, je i ta nejvíc Enterprise technologie příliš nespolehlivá, resp. nedokáže zaručit potřebnou spolehlivost za reálnou cenu.
Takže alespoň pro infrastrukturu, která posyktuje veřejné služby (hledání, mapy, apps), Google údajně používá "obyčejné" komponenty v obrovkém počtu. Problémem je také spotřeba elektřiny, takže se používá to s nejlepším poměrem výkon/spotřeba. Ve své době to byly P3, dnes už asi ne. Spolehlivost je zajištěna a úrovni aplikací. Data jsou v několika kopiích a nemusí být zrovna na tom stroji, který je zpracovává, jsou síťově sdílená. Systém uložení dat např. zajišťuje, že bude uložen určitý počet kopií v každém z datacenter Googlu, aby se data nepřenášela na dlouhé vzdálenosti.
Ale je třeba říct, že přístup Googlu často nelze v prostředí, kde se používá FC / SAN, dost dobře uplatnit. Zjednodušeně se takový přístup začíná vyplácet až od určité velikosti, což je ještě závislé na druhu služeb.
http://www.youtube.com/watch?v=zRwPSFpLX8I
Jakze je to udelane s tou baterkou?
12V - AKU - ZDROJ - DESKA? (jak se dobiji ta aku?)
220V - ZDROJ - AKU-DESKA? (deska ma na sobe nejaky dalsi "zdroj" pro jine napetove vetve?)
Nebo uplne jinak?
---
"Kazdy stroj ma svojho dvojnika niekde inde vo svete"
Jenom jednoho na svete nebo kazdy stroj ma dvojnika v dane lokalite?
A jak se vlastne rozklada takova obrovska zatez? Geograficky DNS servery hodi pozadavky do spravneho datacentra co je "nejblize", porad nejak nerozumim, kdyz muj dotaz treba gmailu doputuje na konkretni server v konkretnim datacentru, jaky mechnismus zajisti, ze tam ten stroj bude mit na discich zrovno moje potreba data. Nebo snad se konkretni uzivatele vzdy dostavaji na tentyz "par"(n-tici) stroju?
U nekterych vyrobcu poli dokonce plati, ze cim vetsi pole tim vetsi cena za GB.Jo, jenže taky to pole pak umí uplně jiné věci, že... :) Třeba FICON, a když máš mainframe, tak na euro nehledíš, jinak by si už dávno měl otevřené systémy.