Americká společnost Reflection AI světu představila Beam, open-weight model s 501 miliardami parametrů (z toho 23 miliard aktivních), určený především pro programování a práci autonomních agentů. Podle autorů jejich model nabízí výkon srovnatelný s většími modely při výrazně nižších nárocích na výpočetní výkon. Beam nyní ještě prochází závěrečným testováním, na stránkách Reflection AI se však lze zaregistrovat a získat předběžný přístup. Váhy modelu, dokumentace a nástroje pro vývojáře mají být zveřejněny v průběhu tohoto měsíce.
OpenCourant je komunitní fork OpenRadioss, tj. open source softwaru pro simulace havárií, nárazů a vysoce nelineárních dynamických dějů metodou konečných prvků. Společnost Siemens v loňském roce dokončila akvizici společnosti Altair Engineering, jež před čtyřmi lety uvolnila open source verzi OpenRadioss svého proprietárního softwaru Radioss. Minulý týden Siemens OpenRadioss pohřbil. Integroval jej do svého softwaru Simcenter, webovou stránku OpenRadioss přesměroval na Simcenter a repozitář OpenRadioss na GitHubu odstranil.
Pořadatelé devátého ročníku komunitního setkání správců nejen českých a slovenských sítí – CSNOG 2027, které se uskuteční 20. a 21. ledna, vyhlásili Call for Abstracts. Náměty na vystoupení mohou zájemci přihlašovat do 31. října na webu akce a vybírat mohou ze tří sekcí – správa sítí, legislativa a regulace a akademické projekty. Zveřejněny byly také Call of Partners určené sponzorům a partnerům setkání, kteří by například chtěli mít na
… více »Strata je open-source inferenční engine, který umožňuje lokálně provozovat rozsáhlý čínský model Qwen3.8-Flash-Next, který by jinak nejspíše vyžadoval serverovou infrastrukturu, na běžném herním počítači s alespoň 12 GB VRAM, 32 GB RAM a dostatkem místa na SSD. Nároky na paměť a rychlost generování se liší s použitou variantou modelu Qwen. Zdrojový kód je dostupný na GitHubu, pod licencí MIT.
Americký prezident Donald Trump oznámil vznik federální Jednotky pro superinteligenci (Super Intelligence Force), která má koordinovat postup vlády, technologických firem, náboženských organizací a dalších institucí v oblasti rychle se rozvíjející umělé inteligence (Trumpem oficiálně nazývanou superinteligencí). SIF, podřízená přímo Trumpovi, má pomoci Spojeným státům udržet v oblasti SI technologický náskok nad světem a
… více »Klient je e-mailový klient pro GNOME s nativní podporou Proton Mailu, PGP a spamfiltrem řízeným AI. Napsaný je v Go s GTK4 a libadwaita. Připojuje se přímo k Proton Mailu (bez Proton Bridge), ke Gmailu, k Seznam.cz a k libovolné schránce IMAP/SMTP. Každou novou zprávu nejdřív posoudí spamfiltr a teprve potom ji ukáže a ohlásí. Rozhraní je česky a anglicky.
Hra Doom nově běží také v SQL databázi CedarDB. Představen byl SQLDoom. Vyzkoušet lze online demo. Zdrojové kódy jsou k dispozici na GitHubu.
Multiplatformní open source aplikace scrcpy (Wikipedie) pro zrcadlení připojeného zařízení se systémem Android na desktopu a umožňující ovládání tohoto zařízení z desktopu, byla vydána v nové verzi 5.0. S podporou hardwarového dekódování videa na desktopu.
Moderní linker mold, rychlejší alternativa k LLVM lld nebo wild, byl vydán v nové major verzi 3.0.0. Přepsán byl z C++ do Rustu.
Po osmi letech od vydání verze 2.0 byla vydána nová major verze 3.0 multiplatformního editoru tagů MusicBrainz Picard (Wikipedie). Přehled novinek, vylepšení a oprav v changelogu.
Aktuální verze jádra je 2.6.18.1, vydaná 16. října. Obsahuje docela dost oprav problémů, které byly odhaleny v 2.6.18.
Byla vydána také verze 2.6.17.14 s menším počtem oprav. Bylo to pravděpodobně poslední jádro řady 2.6.17.x.
Adrian Bunk vydal s několika novými opravami 2.6.16.30-rc1.
Aktuální předverze je 2.6.19-rc2, vydaná 13. října. Kromě několika oprav je tam i velká změna prototypu zpracovávačů přerušení a první začleněná verze vývojového souborového systému ext4. Podrobnosti v dlouhém changelogu.
Od vydání -rc2 bylo do hlavního git repozitáře zařazeno dalších asi 250 patchů - téměř všechno opravy.
Aktuální verze -mm stromu je 2.6.19-rc2-mm1. Mezi nedávné změny patří obecná podpora zařízení s podsvícením a aktualizace FUSE. Byla přidána nová funkce round_jiffies(), která zaokrouhluje časovou hodnotu na další celou vteřinu. Účelem je docílit sjednocení opakujících se časovačů, což sníží počet potřebných přerušení časovačů.
No ne, kdo by si pomyslel, že natažení 6 megabajtů neznámého kódu do jádra a X serveru nemusí být dobrý nápad? Skoro jako by spouštění kódu pod rootem mohlo znamenat nějaké bezpečnostní riziko nebo co.
Funkce pci_set_mwi() umožňuje na PCI sběrnici režim MWI (memory write and invalidate = zápis do paměti a zneplatnění). Pokud zařízení na druhém konci umí pracovat s MWI, dosáhne se určité optimalizace. MWI režim však nemusí být možné zapnout, i když to ovladač vyžaduje; nemusel by ho totiž podporovat hardware sběrnice. Pokud není MWI nastaven, nebývá to obyčejně problém; jen je vše trochu pomalejší. Volající ovladač by však přesto mohl chtít vědět, jestli bylo volání úspěšné, takže Matthew Wilcox funkci nedávno opravil, aby při selhání vracela -EINVAL.
Ukázalo se, že tohle je jeden ze záškodnických patchů, které v poslední těžce zkoušely Vaio Andrew Mortona. Nějaký kód kontroloval výsledek pci_set_mwi(); jakmile funkce začala doopravdy vracet výsledek operace, volající kód selhal. Ale, jak bylo řečeno výše, nenastavený režim MWI skoro nikdy nepředstavuje problém. V reakci na tento sled událostí Alan Cox prohlásil:
Základní chybou je, že někdo označil pci_set_mwi jako must-check [kontrola nutná], což je problém pro většinu ovladačů, které tu funkci používají. Pokud odstraníte "must check", bude po problémech (a zmizí i tisíce dalších falešných varování).
Dá se předpokládat, že Alan má tedy na svědomí například tento kód z drivers/ata/pata_cs5530.c:
compiler_warning_pointless_fix = pci_set_mwi(cs5530_0);
__must_check využívá gcc atribut warn_unused_result; v hlavním jádře to bylo poprvé využito ve verzi 2.6.8. Je-li funkce označena jako __must_check, kompilátor vypíše výrazné varování vždy, když je funkce volána, aniž by byl zpracován její návratový kód.
Využívání __must_check je jedním z kroků na dlouhé cestě k automatickému odhalování potenciálních chyb. Je to určeno pro funkce, jejichž návratové hodnoty skutečně vyžadují kontrolu - dobrým příkladem je copy_from_user(). Pokud tato funkce selže a volající kód si toho nevšimne, bude pokračovat s více méně náhodnými daty. Podobné potíže se objevují v uživatelském prostoru; viz nedávné bezpečnostní problémy vzniklé kvůli tomu, že si aplikace s vyššími právy nekontrolovaly výsledek volání setuid(). V některých případech je ignorování návratové hodnoty skutečně neomluvitelné a __must_check je dobrý způsob, jak nesprávné použití funkce objevit dříve, než to způsobí opravdové problémy.
V posledních jádrech však počet __must_check funkcí poněkud narostl: je to většina sysfs, PCI, kobject a ovladačového API. V některých případech (jako u pci_set_mwi()) je to i u funkcí, jejichž návratové hodnoty volající kód nezajímají. Má to za následek podloudné berličky v kódu, nová varování a skutečnou chybu, při které kód, jež by nemusel selhat, selže v reakci na chybový návratový kód.
Přesto není podle Andrew Mortona dobré ignorovat chybovou návratovou hodnotu z funkce jako pci_set_mwi():
Vy, coby autoři ovladačů, _nevíte_, co v současné době pci_set_mwi() dělá, a co dělá na každé z platforem, nebo co bude dělat v budoucnu. Pokud jako autor ovladače zkoušíte hádat, co se v rámci pci_set_mwi() děje, překračujete hranici vrstvy. Třeba byl bridge za běhu odstraněn. Nebo pokus o nastavení MWI způsobil synchronní PCI chybu. Jako příklad vám mohou posloužit různé implementace pci_ops.read(), které mohou selhat z nejrůznějších důvodů.
Diskuze se nakonec stočila k tomu, co je patrně hlavní otázkou: jak by měla být jaderná API navržena, aby správně vracela návratové informace? Jeden z návrhů říkal, že by pci_set_mwi() měla být upravena tak, aby vracela buď nulu nebo jedničku - podle toho, jestli je provoz v MWI režimu možný nebo ne. Záporný návratový kód by měl být vracen pouze pokud dojde k nějaké drastické chybě na PCI sběrnici. Zatím nebyl začleněn patch, který by to implementoval, ale zdá se pravděpodobné, že tento konkrétní problém bude řešen touto cestou.
Širší diskuze o tom, jak by měly být zpracovávány chyby, však asi teprve začíná. Během času se ustálilo množství de-facto konvencí pro jaderná API, ale zpracování chyb žádná pravidla nemá. Andrew by tedy rád mluvil o tom, jak se chovat k různým druhům chyb. Konkrétně navrhuje pravidlo, které říká, že záporný chybový kód nesmí být nikdy ignorován. Případy, ve kterých takový výsledek není relevantní (čehož je příkladem pci_set_mwi()), jsou známkou, že je nutné API navrhnout znovu.
Jaderná rozhraní se tedy patrně začnou měnit tak, aby nebyly chybové kódy vraceny v situacích, kdy je vše v pořádku. Pokračovat bude i boj s množstvím varování, ve kterých se ztrácejí skutečné chyby. S trochou štěstí to povede k bezpečnějším rozhraním a robustnějšímu jádru.
Systémové volání sysctl() mělo těžký život. Začalo jako nápad importovaný z BSD; umožňuje uživatelskému procesu upravovat různé parametry jádra pomocí sady číselných indexů. Lidi však brzy přišli na to, že textové rozhraní založené na souborovém systému (/proc/sys) se používá mnohem snadněji. Hierarchii /proc/sys lze upravit z prostředí shellu a ovládat skripty - nikdo se nemusí starat o sysctl čísla. Uživatelů sysctl() je tedy velmi málo a už dlouho je považováno za zastaralé. Novější jádra při použití sysctl() zobrazí varovnou hlášku.
Jádra 2.6.19-rc to berou ještě o krok dál: ve většině konfigurací sysctl() úplně zmizí. Pouze pokud je nastavena volba "embedded", je možné zapnout sysctl(). To vše je v souladu s plánem na odstranění, podle kterého by mělo být sysctl() zrušeno v lednu 2007.
Jenže sysctl() je součástí uživatelského API, které by nemělo být nikdy měněno. Odstranění této funkce by porušilo často opakovaný slib, že toto rozhraní bude stabilní. Někteří vývojáři si na změnu API začali stěžovat. Ozvaly se hlasy volající po stáhnutí plánů na odstranění a navrácení sysctl() do běžných konfigurací. Alan Cox k tomu řekl: Přidali jsme to, podporovali jsme to, tak to tam máme. Do dokumentace jen strčíme zmínku "používejte raději /proc".
Už jsou k dispozici patche, které sysctl() obnovují, i když žádný nebyl zatím začleněn. Zdá se, že nepanuje shoda o tom, jestli by odstranění sysctl() skutečně uživatelským aplikacím způsobilo problémy. Starší C knihovny to používají, ale tyto knihovny se při selhání pokusu o využití sysctl() zachovají správně a aplikace fungují normálně. Linus požádal o příklad aplikace, která skutečně přestane bez sysctl() fungovat; zatím se ale neobjevil žádný. Rozhraní, která skutečné systémy nepoužívají, odstraněna být mohou, takže pokud někdo brzy nepřijde s opravdovým problémem, sysctl() bude pravděpodobně pokračovat v nastoupené cestě z jádra.
Následující obsah je © KernelTrap
16. říj, originál
Nedávná zpráva od Rapid7 oznamuje: Linuxový binární ovladač grafických karet nVIDIA obsahuje chybu, kvůli které může dojít k přetečení bufferu, což útočníkovi umožní spouštět libovolný kód jako root. Chybu lze zneužít jak lokálně, tak vzdáleně (přes vzdáleného X klienta nebo když X klient navštíví útočníkem upravenou webovou stránku). K této zprávě je jako důkaz přiložen funkční "root exploit" [exploit = kód schopný zneužít chybu]. Zpráva dále sděluje, že binární ovladače pro FreeBSD a Solaris jsou pravděpodobně stejně zranitelné, a varuje: Jsme toho názoru, že binární ovladače nVIDIA jsou i nadále nepřijatelným bezpečnostním rizikem, což podporuje velký počet reprodukovatelných neopravených pádů, které byly hlášeny ve veřejných fórech a databázích chyb.
Chad Loder z Rapid7 vysvětlil, že nVIDIA už o chybě nějakou dobu ví: Odkaz v naší zprávě ukazuje na nejstarší diskuzní vlákno, ve kterém zaměstnanec nVIDIA veřejně chybu přiznává. I když je to už z roku 2004, je pravděpodobné, že existovala ještě dříve. Ohledně veřejného oznámení exploitu Chad řekl: Očekávám (nebo doufám), že nVIDIA chybu v binárních ovladačích rychle opraví. Nevím nic o jejich vývojovém procesu nebo o tom, kde na jejich žebříčku priorit stojí linuxové ovladače. Vypadá to ale, že většině uživatelů Linuxu vůbec nevadí chyby v kusech binárního kódu od výrobců hardwaru, takže nVIDIA nemá příliš důvod své postupy měnit.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Unauditable je česky neznámý?Není. Ale vzhledem ke kontextu mi to přišlo jako vhodný překlad. Nechtělo se mi do toho svižného citátu vkládat jazykolamy jako "nezkontrolovatelný", "neprozkoumatelný" nebo "neprověřitelný".
Podobně bych přeložil "memory write and invalidate" spíš jako "zápis do paměti a zneplatnění" než "zápis do paměti a zrušení".