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 »
Aktuální vývojové jádro je 3.19-rc1, vydané dne 20. prosince – o jeden den dříve, než se dalo očekávat.
Stabilní aktualizace: minulý týden nebyly vydány žádné stabilní aktualizace.
Wired hovořil s Linusem Torvaldsem o možnostech další chyby spojené s přestupnou sekundou.
Vy všichni ostatní opravdu berte tu přestupnou sekundu jako záminku k uspořádání malého absurdního večírku pro své nejbližší přátele. Nasaďte si srandovní klobouky, nechte si natisknout transparent se slovy „Večírek soudné přestupné sekundy“ a pořádně se opijte. Jednou mrknete a bude po všem, ale aspoň budete mít další den kocovinu, která vám připomene tu slavnou, ale prchavou sekundu navíc.
Přicházejí 100Gb síťové adaptéry, konstatoval Jesper Brouer ve své přednášce na minikonferenci jádra LCA 2015 (snímky [PDF]). Řízení těchto adaptérů v jejich plné podporované rychlosti bude pro linuxové jádro významnou výzvou; řešení tohoto problému je náplní jeho současné i budoucí práce. Dobrou zprávou je, že linuxové síťování se díky tomu trochu zrychlilo – i když je stále nutné vyřešit některé problémy.
Jak síťové adaptéry zrychlují, doba mezi pakety (tj. čas, ve kterém musí jádro zpracovat každý paket) se zkracuje. U současných 10Gb adaptérů je to 1 230 ns mezi dvěma 1538bajtovými pakety. Přenosová rychlost 40 Gb/s tuto dobu výrazně snižuje na 307 ns. 100 Gb/s tento problém přirozeně zhoršuje, protože zkracuje čas na paket na zhruba 120 ns; v tomto případě rozhraní zpracovává 8,15 milionů paketů za sekundu. To nenechává příliš času na to, aby systém zjistil, co se kterým paketem provést.
Co ale máte dělat, pokud – jako většina z nás – nemáte na hraní 100Gb adaptér? Místo něj použijete 10Gb adaptér s malými rámci. Nejmenší ethernetový rámec, který lze odeslat, je 84 bajtů; podle Jespera je u 10Gb adaptéru mezi pakety nejmenší velikosti prodleva 67,2 ns. Systém, který se s takovou zátěží dokáže vyrovnat, by měl být schopen rozumně zvládat 100Gb sítě, až budou k dispozici. Ale vyrovnat se s takovou zatížení je těžké: na 3GHz procesoru máte pro zpracování každého paketu k dispozici pouze asi 200 cyklů procesoru. To, jak poznamenal Jesper, není mnoho.
Jádro se tradičně s tímto druhem síťových intenzivních zatížení nevyrovnává nejlépe. To vedlo ke vzniku řady síťových implementací mimo hlavní strom, které zásobník síťové vrstvy jádra zcela obcházely. Poptávka po takových systémech naznačuje, že jádro nepoužívá hardware optimálně; implementace mimo hlavní strom může řídit adaptéry plnou dostupnou rychlostí z jediného procesoru, což jádro hlavní větve příliš nezvládá.
Problém je podle Jespera v tom, že vývojáři jádra se zaměřovali na škálování na velký počet jader. Během toho se jim dařilo skrývat regrese efektivity na jedno jádro. Zásobník síťové vrstvy v důsledku toho funguje dobře pro více zátěží, ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací doby. Jádro dnes dokáže předávat pouze něco mezi 1 M a 2 M pakety na jádro za sekundu, zatímco některé z nezávislých alternativ se blíží k rychlosti 15 M paketů na jádro za sekundu.
Pokud budete chtít tento druh problému řešit, musíte si důkladně posvítit na režii na každý krok ve zpracování paketu. Tak například řešení neúspěšného přístupu do mezipaměti na Jesperově 3GHz procesoru trvá asi 32 ns. Stačí tedy dva neúspěšné přístupy k vyčerpání celého času vyhrazeného zpracování paketu. Vzhledem k tomu, že vyrovnávací paměť soketů („SKB“) zabírá na 64bitovém systému čtyři řádky mezipaměti a že velká část SKB je zapsána během zpracování paketů, je první část problému jasná – čtyři neúspěšné přístupy do mezipaměti by spotřebovaly mnohem víc času, než je k dispozici.
Mimo to, použití prefixu x86 LOCK pro atomické operace trvá asi 8,25 ns. V praxi to znamená, že nejkratší cyklus uzamčení/odemčení trvá něco přes 16 ns. V takovém časovém limitu tedy není dost místa pro hodně zamykání.
K tomu se přičítá doba potřebná na provedení systémového volání. V systému s aktivní ochranou SELinux a auditováním to zabere lehce přes 75 ns – tedy celou vymezenou dobu. Deaktivace auditování a SELinuxu zkracuje potřebný čas těsně pod 42 ns, což je lepší, ale i tak je to značná část celkového času. Existují způsoby, jak tuto režii vyrovnat v rámci několika paketů; mezi ně patří systémová volání jako sendmmsg(),recvmmsg(),sendfile() nebo splice(). V praxi to ovšem podle něj nefunguje tak dobře, nezjistil ale prý důvod. Christoph Lameter z publika poznamenal, že uživatelé závislí na čekací době mají tendenci používat mechanismus InfiniBand „IB verbs“.
Jesper se potom zeptal, jak je možné, že řešení obcházející jádro dosahují lepších výsledků. Zdá se, že klíčem je dávkové zpracování operací, předběžná alokace a předběžné načítání zdrojů. Tato řešení pracují v režimu CPU-local a předcházejí tak zamykání. Také je důležité zmenšit metadata paketů a snížit počet systémových volání. Pomůžou také rychlejší datové struktury optimalizované pro vyrovnávací paměť. Ze všech těchto technik je nejdůležitější dávkové zpracování operací. Režii, která je nepřijatelná na úrovni paketů, lze lépe zvládnout, pokud se projevuje jednou za desítky paketů. 16ns zamykání na paket je příliš; pokud se současně zpracuje 16 paketů, toto zatížení klesne na 1 ns na paket.
Proto není divu, že Jesperova práce se zaměřuje na zlepšení dávkového zpracování v síťové vrstvě. To zahrnuje práci na hromadném přenosu TCP, o které jsme zde informovali v říjnu; podrobnosti o tom, jak všechno funguje, najdete v tomto článku. Stručně řečeno, jedná se o mechanismus pro informování síťových ovladačů o tom, že existují další pakety čekající na přenos; to umožní ovladači odložit nákladné operace, dokud nejsou všechny tyto pakety zařazeny do fronty. V případě nasazení tohoto mechanismu dokáže jeho systém přenášet 14,8 M paketů za sekundu – tedy, pokud se stále dokola posílá stále jeden malý paket.
Nejsložitější podle něj je přidání dávkově pracujících API do zásobníku síťové vrstvy bez zvýšení latence systému. Latence a propustnost si velmi často konkurují; tady je cílem optimalizace obou. Obzvlášť těžké je odolat spekulacím se zpožděním přenosu – vsadit na to, že se brzy objeví další paket. Takové triky často zlepší výsledky benchmarků, ale jsou méně vhodné pro skutečné zatížení.
Dávkové zpracování může – a mělo by – probíhat v několika vrstvách zásobníku. Vhodným místem pro dávkové zpracování je například systém disciplín ukládání do fronty („qdisc“); při řazení do fronty už tak jako tak dochází ke zpoždění. V nejlepším případě vyžaduje kód qdisc v současnosti šest operací LOCK na paket – 48 ns čisté režie uzamykání. Celková režie na řazení paketů do front je 58–68 ns, většinu času tedy spotřebují operace zamykání. Jesperova práce spočívala v přidání dávkového zpracování, aby se režie rozložila na několik paketů; to ale funguje jen v případě, že taková fronta paketů existuje.
Nominální rychlý průchod kódem qdisc nastává, když neexistuje žádná fronta; v takových situacích mohou být pakety často předány přímo do síťového rozhraní bez řazení do fronty. V současnosti takové pakety provází režie všech šesti operací LOCK. Podle něj by to mělo jít lépe. Subsystém qdisc bez zámků by mohl odstranit téměř veškerou režii na řazení paketů do fronty. Jesper má testovací implementaci, na které předvádí, čeho lze dosáhnout; eliminace minimálně 48ns režie za to podle něj stojí.
Zatímco výkon odesílání podle něj nyní vypadá poměrně dobře, zpracování příjmu by se stále mohlo ještě trochu zlepšit. Vysoce vyladěná konfigurace může dosáhnout rychlosti maximálně asi 6,5 M paketů za sekundu – a v takových případech se pakety jednoduše zahazují po příjmu. Probíhají určité práce na optimalizaci průběhu příjmu, které toto maximum zvýší na něco přes 9 M paketů za sekundu. Problém je ale v benchmarku: ten neukazuje režii na interakce se subsystémem správy paměti.
A ukazuje se, že tato interakce je velmi slabá. Přenosová cesta zásobníku síťové vrstvy má podle všeho některé vzorce chování, které nevedou k nejlepšímu způsobu práce alokátorů tabulek. Přijímací kód může přidělit prostor až pro 64 paketů současně, zatímco přenosová cesta může uvolňovat dávky až po 256 paketech. Tento vzorec podle všeho poměrně zpomaluje především alokátor SLUB. Jesper provedl nějaké mikrobenchmarky a zjistil, že jedno volání kmem_cache_alloc() následované voláním kmam_cache_free() vyžaduje asi 19 ns. Pokud se ale provádělo 256 přidělení a uvolnění, tato doba narostla na 40 ns. V zásobníku síťové vrstvy v reálném prostředí, kde současně probíhají další procesy, může ale režie přidělování a uvolňování narůst ještě více, na 77 ns – více než celý vyhrazený časový rámec.
Proto Jesper dospěl k závěru, že je nutné kód správy paměti vylepšit nebo nějakým způsobem zcela obejít. V rámci testů druhé z variant implementoval subsystém nazvaný qmempool; ten provádí hromadné operace přidělování a uvolňování bez zamykání. Díky qmempool byl schopen ušetřit 12 ns v jednoduchých testech a až 40 ns v testech předávání paketů. Existuje celá řada způsobů zrychlení používaných v qmempool, navrch má ale dávkové zpracování operací.
Jesper skončil tím, že uvedl, že qmempool implementoval jako jakousi provokaci: chtěl ukázat, co je možné, a přimět vývojáře správy paměti, aby s tím něco udělali. Odpověď z tábora správy paměti následovala v další přednášce, která bude zveřejněna samostatně.
[Editor by chtěl poděkovat linux.conf.au za financování jeho cesty na tuto akci.]
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
25.3.2015 11:11
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
26.3.2015 09:33
Conscript89
| Brno
26.3.2015 03:20
Jendа | skóre: 78
| blog: Jenda
| JO70FB
ale utrpěly pracovní zátěže, které jsou obzvláště citlivé na čekací dobyTo je workload? Přeložil bych to jako typy zátěží.
27.3.2015 10:09
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
LOCK (instrukčním) prefixem, což je hardwarová záležitost.
27.3.2015 13:40
Jendа | skóre: 78
| blog: Jenda
| JO70FB
. BTW to se už skoro dá implementovat raw video-out over ethernet ne?
30.3.2015 21:45
Petr Tomášek | skóre: 39
| blog: Vejšplechty