Byla vydána (𝕏) nová verze 2025.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení na blogu.
Dánské ministerstvo pro digitální záležitosti má v plánu přejít na Linux a LibreOffice [It's FOSS News].
V úterý Google vydal Android 16. Zdrojové kódy jsou k dispozici na AOSP (Android Open Source Project). Chybí (zatím?) ale zdrojové kódy specifické pro telefony Pixel od Googlu. Projekty jako CalyxOS a GrapheneOS řeší, jak tyto telefony nadále podporovat. Nejistá je podpora budoucích Pixelů. Souvisí to s hrozícím rozdělením Googlu (Google, Chrome, Android)?
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.101 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.101 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
V Brně na FIT VUT probíhá třídenní open source komunitní konference DevConf.CZ 2025. Vstup je zdarma, nutná je ale registrace. Na programu je celá řada zajímavých přednášek, lightning talků, meetupů a workshopů. Přednášky lze sledovat i online na YouTube kanálu konference. Aktuální dění lze sledovat na Matrixu, 𝕏 nebo Mastodonu.
Vyloučení technologií, které by mohly představovat bezpečnostní riziko pro stát, má umožnit zákon o kybernetické bezpečnosti, který včera Senát schválil spolu s novelami navazujících právních předpisů. Norma, kterou nyní dostane k podpisu prezident, počítá rovněž s prověřováním dodavatelů technologií pro stát. Normy mají nabýt účinnosti od třetího měsíce po jejich vyhlášení ve Sbírce zákonů.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.6.
Po Red Hat Enterprise Linuxu a AlmaLinuxu byl v nové stabilní verzi 10.0 vydán také Rocky Linux. Přehled novinek v poznámkách k vydání.
Bylo vydáno Eclipse IDE 2025-06 aneb Eclipse 4.36. Představení novinek tohoto integrovaného vývojového prostředí také na YouTube.
Americká filmová studia Walt Disney a Universal Pictures podala žalobu na provozovatele populárního generátoru obrázků pomocí umělé inteligence (AI) Midjourney. Zdůvodňují to údajným porušováním autorských práv. V žalobě podané u federálního soudu v Los Angeles označují firmu za „bezednou jámu plagiátorství“, neboť podle nich bez povolení bezostyšně kopíruje a šíří postavy z filmů jako Star Wars, Ledové království nebo Já, padouch, aniž by do nich investovala jediný cent.
Ocenil bych jednu informaci – ptal jsem se na to i borce na jedné konferenci (po přednášce o tom jak je FCoE super a máme si ho koupit) – jaká je režie IP protokolu? Zajímá mne srovnání iSCSI a FCoE za jinak stejných okolností. Rád bych slyšel konkrétní čísla, protože od něj jsem se dozvěděl, že režie IP protokolu je strašně velká. A vůbec, je to nesrovnatelné, protože na FCoE je potřeba mít 10Gbps ethernet a na tom on iSCSI nikde neprovozoval. Takže, pokud budu mít FCoE a iSCSI na stejně rychlé síti (ať už 1 nebo 10 nebo třeba 100 Gbps), o kolik bude FCoE rychlejší?
Svého času jsem provedl experiment - náhodou se mi na stole sešlo železo, které ho umožňovalo: dvě síťovky Myri-10G, externí RAIDový box s řadičem Areca na úrovni ARC-1680 (ale propoj PCI-e pouze x4), nějaký server s čipsetem Intel 5000P (CPU Xeon tuším 5300 series), jako koncové zařízení (iSCSI initiator) nějaký "průmyslový desktopový" board tuším s i945, který podporuje v x16 slotu i jiné věci než grafiku (zde iSCSI kartu).
Desktop | Server | | RAID | 10Gb Eth <======> 10Gb Eth | PCIe x4 <=====> PCIe x4
Použil jsem "alternativní" softwarový SCSI target pro Linux SCST, který mj. obsahuje také iSCSI front-end. Jako back-end umí použít libovolné blokové zařízení buď s použitím systémového bufferingu (VM), nebo bez bufferingu v "direct módu" (bDIRECT), nebo snad i s přímým relayem SCSI příkazů. SCST žije celý v kernelu a je optimalizován na průchodnost.
Mám pocit, že Intel I/OAT v čipsetu 5000 jsem nepoužil - jednak mi to v Linuxu nechtělo chodit, jednak to možná nechodí se síťovkou jinou než Intel, jednak to vlastně v Linuxu má odlehčovat jenom "copy to user", což je dost k ničemu, když SCST žije celý v kernelu (viz níže).
Samotný RAID mi dával přímo proti serveru sekvenční LBA čtení cca 600 MBps. Když jsem ho přes iSCSI namapoval "klientovi" (initiatoru) na tom desktopovém stroji, tak desktopový stroj z toho vytáhl sekvenční LBA čtení 500 MBps (v jedné relaci). Provedl jsem jenom nějaké lehké ladění dostupnými prostředky:
Ono je nakonec možné, že pro většinu aplikací ty sekvenční MBps jsou honěním trička. Důležitým číslem jsou IOps. Pokud uvážíte nevelkou standardní hloubku TCQ front na několika zúčastněných vrstvách, tak se do toho poměrně přímo promítá doba zpracování jednotlivého požadavku, potažmo i přenosové latence. Latence na běžném Ethernetu (neřku-li TCP/IP) jsou nepochybně delší, než latence na klasických storage sběrnicích.
V tomto směru bohužel žádné benchmarky nemám.
Strašlivá režie vrstev TCP/IP má několik faset. Pokud se týče ztráty kapacity na vrub enkapsulace, jsou to tuším nějaké jednotky procent při MTU=1500 (= ztráta zanedbatelá). Jiná věc je "processing overhead", tj. spotřeba procesorového výkonu na počítání algoritmů a spotřeba průchodnosti sběrnic na "zbytečné" kopie dat. Nějaká čísla jsou tady, ovšem podle mých experimentů zjevně neaktuální pro dnešní hardware - mají snad nějakou relativní hodnotu. A ještě jiná věc je režie způsobená reakcemi "TCP/IP flow control" (regulační smyčky) - tj. rozjezd spojení, přibržďování oknem, a nedejbože retransmit při ztrátě paketu, ó hrůzo.
Protože mě storage hardware v podstatě neživí, dovolím si pár odhadů selským rozumem a laických pivních prohlášení "Hrozný overhead iSCSI" znamená víceméně tolik, že netriviální logika vrstev TCP/IP se nesnadno implementuje v čistém hardwaru, a navíc zejména za nepříznivých okolností (vytížení sítě směsí různého provozu) může projevovat náhodné vyšší latence. Proto si vymyslíme jednodušší enkapsulaci celých FC rámců, která pojede přímo nad Ethernetem, nebude mít vlastní garanci doručení, proto bude implementačně jednoduchá. Garanci doručení pak doženeme jednoduchými recepty, známými z minulosti (absolutní priorita pro náš provoz, a (802.3x)802.1bb flow-control v Ethernetu) - že jednoduché recepty mohou mít své mouchy, zejména v prostředí se složitým mixem "best effort" provozu, to ať si vyřeší někdo jiný. Když dáme povinně 10Gb Ethernet, tak s trochou štěstí bude úzké hrdlo někde jinde (reálné targety nebo initiatory). Ostatně "přibržďování toku" si v moderním SCSI provozu řeší TCQ s podobným efektem, jako má TCP receive window (až na to, že ztráta FCoE paketu znamená SCSI command timeout, což je docela závažná chyba).
Abych nebyl zase tolik zbytečně ošklivý, ono má asi smysl, v nějaké složitější síti, tj. v systému, kde spolu soupeří spousta datových toků na vrstvách síťové komunikace a storage komunikace, aby storage komunikace měla obecně přednost - aby se provoz škrtil a hltil přednostně na internetové vrstvě (kde je to jaksi snáze omluvitelné), ale aby počítače měly pokud možno vždycky dostupné disky. Je možné, že to v globále vede k lepší stabilitě systémů. Podmínkou je, aby nějaká aplikace nežrala IO bandwidth "nadoraz, co to dá" - to je právě problém s absolutní priorizací. Stejně jsem ale zvědav, jak jsou na FCoE ošetřeny problémy typu "head of line blocking". A mimochodem, té priorizace by se možná dalo dosáhnout třeba i levněji s klasickými switchi, pomocí 802.1p, ne?
Jestli někdo potřebuje storage síťku na capture HD videa, tzn. vyžaduje striktně deterministické odezvy (dokonce nejen od blokové vrstvy, ale od filesystému, chacha) tak by možná měl sáhnout spíš po FC než po FCoE.
iSCSI HBA třeba od Adaptecu mívaly tuším svého času prostě jenom síťovku Intel, která byla vybavena trochu jinou option ROMkou a ovladači pro Windows, aby se to v BIOSu tvářilo jako SCSI řadič. Čili nějaký kompletní offload iSCSI do hardwaru se v podstatě nekonal.
Když se FCoE před časem začalo objevovat, mluvilo se o tom, že ethernetové switche pro tento provoz jsou stavěny speciálně na super-nízké latence. Čili není to normální kancelářský Ethernet. Máte někdo představu, kolik tyhle hračky stojí? Je to cenově blízko ke konvenčnímu Ethernetu, nebo spíš k FibreChannelu?
>> Strašlivá režie vrstev TCP/IP má několik faset.
>>
> doteď jsem byl dojmu, že fazeta je skosená hrana.
> nebo se normálně používá i v tomhle kontextu?
>
obrazně řečeno. Několik aspektů. Fakt je, že jsem to slovo takhle použité potkal asi spíš v anglině než v češtině. Omlouvám se tedy za neblahý novotvar
F.Ryšánek
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
24.2.2010 00:58
24.2.2010 11:45
24.2.2010 12:48