Byla vydána nová verze 1.12.0 dynamického programovacího jazyka Julia (Wikipedie) určeného zejména pro vědecké výpočty. Přehled novinek v příspěvku na blogu a v poznámkách k vydání. Aktualizována byla také dokumentace.
V Redisu byla nalezena a v upstreamu již opravena kritická zranitelnost CVE-2025-49844 s CVSS 10.0 (RCE, vzdálené spouštění kódu).
Ministr a vicepremiér pro digitalizaci Marian Jurečka dnes oznámil, že přijme rezignaci ředitele Digitální a informační agentury Martina Mesršmída, a to k 23. říjnu 2025. Mesršmíd nabídl svou funkci během minulého víkendu, kdy se DIA potýkala s problémy eDokladů, které některým občanům znepříjemnily využití možnosti prokázat se digitální občankou u volebních komisí při volbách do Poslanecké sněmovny.
Společnost Meta představila OpenZL. Jedná se o open source framework pro kompresi dat s ohledem na jejich formát. Zdrojové kódy jsou k dispozici na GitHubu.
Google postupně zpřístupňuje českým uživatelům Režim AI (AI Mode), tj. nový režim vyhledávání založený na umělé inteligenci. Režim AI nabízí pokročilé uvažování, multimodalitu a možnost prozkoumat jakékoliv téma do hloubky pomocí dodatečných dotazů a užitečných odkazů na weby.
Programovací jazyk Python byl vydán v nové major verzi 3.14.0. Podrobný přehled novinek v aktualizované dokumentaci.
Bylo oznámeno, že Qualcomm kupuje Arduino. Současně byla představena nová deska Arduino UNO Q se dvěma čipy: MPU Qualcomm Dragonwing QRB2210, na kterém může běžet Linux, a MCU STM32U585 a vývojové prostředí Arduino App Lab.
Multiplatformní open source voxelový herní engine Luanti byl vydán ve verzi 5.14.0. Podrobný přehled novinek v changelogu. Původně se jedná o Minecraftem inspirovaný Minetest v říjnu loňského roku přejmenovaný na Luanti.
Byla vydána nová stabilní verze 6.10 (YouTube) multiplatformního frameworku a GUI toolkitu Qt. Podrobný přehled novinek v poznámkách k vydání.
Současný vývojový kernel je 4.8-rc7, vydaný 18. září. Linus k tomu řekl: „Běžně je rc7 poslední před ostrým vydáním, ale nyní jsem si jistý, že tohle bude jeden z těch cyklů, kdy dojde na rc8. Věci se neuklidnily do té míry, jak bych si přál, pořád probíhají nějaké diskuze a je nepravděpodobné, že do neděle bude vše připraveno na vydání 4.8.“
Viz tento seznam pro shrnutí aktuálně známých regresí ve 4.8.
Stabilní aktualizace: 4.7.4, 4.4.21 byly vydány 15. září.
Víme, že hlášení chyb proudí od všech, „software bez chyb“ neexistuje a nikdo z nás netvrdí opak. To, co tvrdíme, je, že byste se měli držet stromu, který je testovaný co největším počtem lidí (tzn. hlavního stromu), protože tím si zajistíte nejvíce oprav a také možnost získat pomoc jaderné komunity v případě problémů. Jinak na to jste sami se 2,5 miliony řádek přidanými do svého frankenjádra, na které nikdo nesáhne, pokud nebude muset.
Jen říkat „nejprve upstream“ pořád dokola a připomínat lidem, že dělat něco jiného je hloupé, věci kupředu neposune. Tohle už lidé slyšeli, ale pro velkou část odvětví existuje velká propast mezi prostým prohlášením a konkrétními kroky, které by se v tomto směru daly přímo podniknout. Někdo to dokonce může považovat za odmítavé a nepřátelské. Bylo by mnohem produktivnější uznat realitu, se kterou se lidé potýkají, a bavit se o tom, jak je možné zlepšit jejich zapojení se do upstreamu, zlepšit situaci a zaplnit mezery.
Když někdo ve spojení s šifrováním řekne, že je to „hezky jednoduché“, často to není ani hezké, ani jednoduché.
Jde o to, že mám podezření, že komunita kolem blokové vrstvy se zajímá akorát o propustnost, zatímco řeči o latenci a interaktivitě jsou vnímány jako otravné vyrušování.
Jako děti, které na zadním sedadle auta vymýšlejí objížďky na chytání pokémonů, když řídíte a jedete na nějaké důležité místo. Chápete, co mám na mysli? Jejich problémy nejsou vaše problémy, takže vás to ani moc nezajímá. Řeknete něco jako: „Jo, jo. Pokémoni. Někdy se o tom pobavíme.“
Algoritmy pro řízení zahlcení jsou nepřitažlivé kusy kódu, umožňující síťovým protokolům (obvykle TCP) maximalizovat propustnost libovolného zadaného spojení a zároveň spravedlivě sdílet dostupnou šířku pásma s ostatními uživateli. Nové algoritmy nemají tendence vyvolávat velké vlny vzrušení. Přidání TCP New Vegas během začleňovacího okna 4.8 vyvolalo jen drobné pozdvižení. Algoritmus BBR (Bottleneck Bandwidth and RTT), který nedávno vydala společnost Google, přitahuje pozornosti více. Odklání se totiž od tradičních mechanismů, které tyto algoritmy používaly, a snaží se dosáhnout lepších výsledků v síti charakterizované bezdrátovými spojeními, vměšujícími se dalšími zařízeními a bufferbloatem.
Problém, který musí každý algoritmus řízení zahlcení řešit, je ten, že síť nemá žádný mechanismus, kterým by koncový uzel informoval o konkrétnímu spojení dostupné šířce pásma. Takže algoritmus musí tak nějak sám přijít na to, kolik dat může kdy poslat. Protože dostupná šířka pásma se bude v průběhu času měnit, musí být daný odhad šířky pásma občas revidován. Jinými slovy, algoritmus pro řízení zahlcení musí udržovat neustálý odhad o tom, kolik dat je možné poslat, na základě informací, jež má k dispozici.
Tyto informace jsou poněkud neúplné. Algoritmy většinou pracují s jednou metrikou, kterou dokážou jednoduše měřit: počet paketů, které se nedostanou na druhý konec spojení a je nutné je vyslat znovu. Když síť běží hladce, měly by zahozené pakety být vzácností. Jakmile se ale začne buffer routeru zaplňovat, nezbude než zahodit pakety, pro které již není místo. Zahazování packetů je tedy docela spolehlivým signálem o překročení šířky pásma daného spojení, a proto by se mělo zpomalit.
Problém s tímto přístupem na síti, jakou máme dnes, je ten, že buffery mezi jakoukoli dvojicí koncových uzlů mohou být obrovské. Příliš velké buffery jsou již několik let považovány za problematické a bylo dosaženo pokroku při zmírňování problémů, které z bufferbloatu vyplývají. Jenomže svět je i nadály plný nafouknutých routerů a některé technologie linkové vrstvy, například WiFi, pro optimální výkon vyžadují určitou míru ukládání do bufferu. V okamžiku, kdy koncový uzel odešle tolik dat, že někde ve spojení dojde k přetečení bufferu, může být objem bufferovaných dat obrovský. Signál o ztrátě paketů jinými slovy dorazil příliš pozdě a v době jeho přijetí již mohlo přetížení spojení na druhém koncovém uzlu trvat delší dobu.
Algoritmy založené na „ztrátách“ se mohou také dostat do problémů, když jen krátce platné podmínky způsobí zahození paketu. Mohou zbytečně zpomalit a ve výsledku selhat ve využívání dostupné šířky pásma.
Algoritmus BBR se od většiny stávajících algoritmů liší v tom, že si ztracených paketů téměř nevšímá. Místo toho je jeho primární metrikou skutečná šířka datového pásma, založená na datech skutečně doručených. Kdykoli je přijat potvrzovací paket, BBR aktualizuje svá měření množství doručených dat. Součet doručených dat za nějakou určitou dobu představuje docela dobrý ukazatel šířky pásma, které je spojení skutečně schopné poskytnout, neboť příslušnou šířku pásma nedávno prokazatelně poskytlo.
Při navázání spojení bude BBR ve stavu „startup“. V tomto stavu se chová jako běžný algoritmus řízení zahlcení v tom, že začíná pomalu, ale rychle navýší přenosovou rychlost ve snaze změřit dostupnou šířku pásma. Většina algoritmů bude pokračovat ve stupňování, dokud nezaznamená ztrátu paketů. BBR místo toho sleduje měření šířky pásma popsaná výše. Zejména se dívá na skutečně dodanou šířku páska za poslední tři cykly a sleduje změny. Jakmile přestane šířka pásma narůstat, dojde BBR k záběru, že optimální šířka pásma spojení byla nalezena, a zastaví stupňování. Je možné, že se tak stane ještě předtím, než se začnou ztrácet pakety.
Naměřená hodnota je poté považována za frekvenci, se kterou by měly být pakety skrze spojení posílány. Ale při měření této frekvence BBR po nějakou dobu nejspíše posílalo pakety vyšším tempem, takže některé budou pravděpodobně čekat ve frontách na doručení. Ve snaze odčerpat tyto pakety z bufferu, kde se hromadí, se BBR přesune do stavu „drain“, v němž bude vysílat pakety s menší frekvencí, než jaká odpovídá naměřené šířce pásma, dokud se frekvence odesílání paketů po počáteční špičce neustálí.
Jakmile je tato vyrovnávací fáze hotova, přepne se BBR do režimu pohotovosti, při kterém vysílá přibližně s vypočítanou šířkou pásma. Přibližně proto, že se vlastnosti síťového spojení v průběhu času mění, takže skutečná šířka pásma musí být neustále monitorována. Navíc, zvětšení skutečné šířky pásma se dá detekovat pouze při občasných pokusech vysílat vyšší rychlostí, takže BBR bude zhruba 1/8 času škálovat rychlost o 25 % nahoru. Pokud se šířka pásma nezvětší (odesílání vyšší rychlostí nebude vést k dodávání dat vyšší rychlostí), bude po fázi této zkoušky následovat opětovná fáze „drain“, aby došlo ke srovnání měření.
Jedním ze zajímavých aspektů BBR je, že na rozdíl od většiny ostatních algoritmů nevyužívá okna zahlcení jako primární prostředek pro řízení odchozího provozu. Okno zahlcení omezuje maximální množství dat, která mohou být v jakémkoli okamžiku „na cestě“. Navýšení objemu okna bude mít obecně za následek dávky paketů, které zaberou nově dostupnou šířku pásma. Oproti tomu BBR používá k odesílání dat ve správnou dobu plánovač paketů tc-fq. Okno zahlcení je stále přítomno pro případ, že by bylo v oběhu příliš mnoho dat, ale již není hlavním regulačním mechanismem.
Poslední komplikace: mnoho síťových spojení podléhá dohledu dalších zařízení, jež omezují maximální datové toky jednotlivých spojení. Pokud jde o tento případ, nemá smysl snažit se překročit maximální povolenou rychlost. Kód BBR vyhledává časové úseky s podezřele stagnující šířkou pásma (v 4Kb/s rozsahu) a vysokou ztrátovostí paketů. Když na ně narazí, vyhodnotí, že kdesi ve smyčce se nachází příslušné zařízení, a šířku pásma omezí na úroveň, při které tento už pakety zahazovat nebude.
Sadu patchů s BBR zaslal Neal Cardwell. Kód samotný nese podpisy spousty lidí, patří mezi ně Van Jacobson či Eric Dumazet. Google, jak říkají, BBR používá již delší dobu a očividně je s výsledky spokojen. BBR funguje velmi dobře, když ho používá jen jedna strana spojení, takže každé nasazení, pokud se naplní očekávání, by mělo internet učinit lepším. Neměli bychom ani čekat dlouho – správce síťového subsystému, David Miller, patche aplikoval, což znamená, že by BBR měl být dostupný ve vydání 4.9.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz