Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 156 (pdf).
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.
Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.
Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.
Ubuntu nově pro testování nových verzí vydává měsíční snapshoty. Dnes vyšel 4. snapshot Ubuntu 25.10 (Questing Quokka).
Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.
Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.
Společnost Framework Computer představila (YouTube) nový výkonnější Framework Laptop 16. Rozhodnou se lze například pro procesor Ryzen AI 9 HX 370 a grafickou kartu NVIDIA GeForce RTX 5070.
Google oznamuje, že na „certifikovaných“ zařízeních s Androidem omezí instalaci aplikací (včetně „sideloadingu“) tak, že bude vyžadovat, aby aplikace byly podepsány centrálně registrovanými vývojáři s ověřenou identitou. Tato politika bude implementována během roku 2026 ve vybraných zemích (jihovýchodní Asie, Brazílie) a od roku 2027 celosvětově.
Byla vydána nová verze 21.1.0, tj. první stabilní verze z nové řady 21.1.x, překladačové infrastruktury LLVM (Wikipedie). Přehled novinek v poznámkách k vydání: LLVM, Clang, LLD, Extra Clang Tools a Libc++.
Aktuální vývojová verze jádra je 3.2-rc6 vydaná 16. prosince. Linus byl trochu nevrlý kvůli opožděným žádostem o přetažení, ale vidí to tak, že se šrumec brzy uklidní. Dospěli jsme k -rc6 a ačkoliv si dovedu představit -rc7, tak do -rc8 nepůjdu, leda by se vynořilo něco špatného. Nevidím žádný dobrý důvod, proč toto vydání ještě více oddalovat a konečnou verzi 3.2 budeme mít asi kolem Nového roku.
Stabilní aktualizace: stabilní jádra 2.6.32.51, 3.0.14 a 3.1.6 vyšla 21. prosince. Každé z nich obsahuje dlouhý seznam důležitých oprav, upgrade je doporučován.
Hmm. Tento patch vypadá, že je zjevně korektní. Ale je korektní natolik zjevně, až jsem z toho trochu podezřívavý.
Tak či tak, bát se, že člověk sejde z vyšlapané cestičky, znamená mít až moc strachu pro práci na RCU. Jenže implementace RCU někdy potřebuje rozumnější přístup. V těchto situacích musím najít nějaký jiný ventil pro mou šílenost. Jinak by to znamenalo, že RCU rozbiju. Naštěstí mi tentokrát jako ventil posloužil nový správce oken Unity v Ubuntu.
Byla ohlášena nová knihovna libkmod a sada nástrojů (kmod-*) pro práci s jadernými moduly. Smyslem je dát nástrojům v počátcích bootování, instalátorům, udevu a dalším věcem snadnou možnost získávat informace a řídit moduly přes knihovnu namísto spouštění modprobe. Na aktuálních linuxových desktopech (a také několika embedded systémech) je při startování počítače udev zodpovědný za zjišťování, jaký hardware je dostupný, vytváření speciálních souborů v /dev (nebo alespoň nastavování práv k nim) a načítání jaderných modulů pro dostupný hardware. U distribučních jader je běžně dát většinu těchto věcí jako moduly. Udev prozkoumá /sys, aby se dozvěděl, co za hardware je k dispozici, a pokusí se potřebné moduly načíst. Toto ve výsledku znamená stovky volání binárky modprobe a v několika z nich jde jen o to zjistit, zda je modul už načtený nebo zda je součástí jádra. S libkmod je možné, aby šlo v udevu všechno udělat pár řádky kódu, což má ještě výhodu v tom, že jsou konfigurace a indexy už načtené a zpracované. Projekt také nabízí programy používající libkmod fungující podobně jako insmod, lsmod a rmmod a nekompletní obdobu modprobe s plány na doplnění této sady. (Díky patři Luisi Felipu Stranu Moraesovi.)
Jednou z pokračujících ozvěn po kompromitování kernel.org je rostoucí zájem o ověřování integrity žádostí o přetažení zasílaných Linusovi. Jedním způsobem, jak toto zajistit, je přidat kryptografický podpis do e-mailu s žádostí o přetažení. Pokud je součástí zprávy ID commitu, žádost o přetažení (a kód, o který se jedná) může být autentizován, ale samotný digitální podpis není uložen v repozitáři, což komplikuje další ověřování v budoucnu.
Alternativou je použít git k vytvoření podepsaného tagu, který uloží podpis v repozitáři. V budoucnu se toto může stát přijímaným způsobem, jak dostat kód do hlavní řady. Linus popsal některé zbývající změny v gitu, které usnadní získání a zaznamenání této informace. Je to dokonce tak jednoduché, že už není třeba dělat si hlavu z větví a jedinečných názvů tagů:
Zpráva pro všechny: nyní můžete vytvořit podepsaný tag a nasměrovat mě k němu. Dokonce už nemusíte ani vytvářet oddělenou větev, stačí jen podepsaný tag.
Takže by bylo nakonec lepší, kdybyste používali dočasné názvy tagů tak, jak používáte dočasné názvy větví, když mě žádáte o přetažení. Tag *content* [obsah] bude odteď ukládán (leda bych něco zkazil při cestování a přetahoval na stroji, kde je starší verze gitu), takže oddělené ukládání tagů se škaredými názvy pod dlouhá léta nemá moc předností.
Toto všechno zjevně funguje už teď s existujícími stabilními vydáními gitu; jen proces začleňování takového tagu vyžaduje novější kód. Takže brzy mohou podepsané tagy být standardním způsobem pro identifikaci změn, které se mají přetáhnout.
Program Kernel Summitu 2011 nezahrnoval Android jako téma, ale tak či tak na něj došlo. V závěru debaty, který mnoho lidí překvapil, se odsouhlasilo, že většina jaderného kódu Androidu by se asi měla začlenit do hlavní řady. Během posledních několika let se ukázalo, že Android jen tak nezmizí; obzvláště dobře se mu daří přežít odpor k začleňování jeho kódu. Po Summitu se věci okolo Androidu zase uklidnily, ale to neznamená, že by se nic nedělo.
Tim Bird nedávno oznámil projekt usilující o začlenění Androidu do hlavní řady, což by mělo pomoci s koordinací různých skupin lidí, co na tomto pracují. Projekt má svou obligátní wiki a mailing list. Mailing list je nový a moc se toho tam ještě nedělo – ale to se může v budoucnu změnit.
Koncem listopadu se jádro androidího kódu vrátilo do stromu staging, odkud bylo odstraněno na konci roku 2009. Od návratu do staging přicházejí změny a kód tam dohnal aktuální stav ve stromu Androidu. Kód se nyní dokonce dostal do stavu, kdy, jak to 16. prosince shrnul Greg Kroah-Hartman:
příští vydání linux-next by skoro mělo nabootovat do uživatelského prostoru Androidu, schází jen jeden dílek – ashmem – a ten by se měl doufejme dostat do stromu staging-next příští víkend. Ostatní tyto patche nadále testují a pročisťují.
Pohledem na wiki a drivers/staging/android v linux-next získáte solidní představu o stavu jednotlivých patchů. Jedním z významných patchů, které tam nejsou, jsou zámky probouzení [wakelocks] (nebo „blokování uspání“), což je funkce vyvolávající nejvíce kontroverze kolem androidího kódu. Koncept zámků probouzení se někdy jistě vrátí, ale lidé se teď spíš soustředí na jednodušší komponenty. Jak Greg poznamenal, zámky probouzení nejsou k nastartování systému s Androidem potřeba – jsou nutné jen k tomu, aby systém nevybil baterii příliš rychle.
Mezi díly této skládačky, které jsou teď ve staging adresáři linux-next, patří:
„Pmem“ je odpovědí Androidu na odvěký problém s alokací rozsáhlých, fyzicky souvislých bufferů, když už systém nějakou chvíli běží. Pracuje obvyklým způsobem: při startu je odložena stranou část paměti. Pmem se odlišuje tím, že do uživatelského prostoru exportuje zařízení, které umožňuje alokování bufferů aplikacemi a předání ovladačům. To nakonec vede k takovým věcem, jako jsou ovladače webkamer napsané s předpokladem, že jim uživatelský prostor může dát fyzicky souvislé buffery pro snímky videa, což je v hlavní řadě jádra nemožné.
Přístup, jakým je CMA, se zdá být lepším řešením tohoto konkrétního problému – pokud a jakmile bude CMA začleněno do hlavní řady. Mezitím byly ale aplikace napsány s použitím pmem, takže je nepravděpodobné, že toto rozhraní v blízké budoucnosti zmizí.
Komponenta „ashmem“ nebyla v době psaní tohoto textu v linux-next, ale jak Greg poznamenal, měla by se tam dostat v blízké budoucnosti. Ashmem je mechanismus sdílené paměti, který dokáže odstranit část nebo celý obsah, jakmile začne paměť docházet. Mohlo by to možná být nahrazeno navrhovanou operací POSIX_FADV_VOLATILE, ale ta nevypadá, že by zatím dokázala plně splnit požadavky Androidu.
Existuje řada změn specifických pro Android, které nejsou v tomto výčtu, a proto není pravděpodobné, že budou do hlavní řady brzy začleněny. Některé z nich jsou natolik specifické pro Android, že se tam nemusí nikdy dostat; do této skupiny patří různé hrátky se „zabezpečením síťování“. Ostatní, jako je kód časovače [alarm timer], už mohly být překonány něčím jiným v hlavní řadě. Dále je tu samozřejmě dlouhá řada ovladačů pro hardware v zařízeních s Androidem. Docela dost takových ovladačů se už do hlavní řady dostalo, další jsou na cestě.
Abychom to shrnuli: pokud se všechno povede, jádro verze 3.3 by mělo rozdíly mezi androidími jádry a hlavní řadou značně zmenšit. To by mělo vývojářům a výrobcům, kteří chtějí nabízet hardware kompatibilní s Androidem, usnadnit život. Samozřejmě nikoho nepřekvapí, pokud do Androidu přibudou nové speciální subsystémy; vývojáři Androidu dali jasně najevo, že nechtějí a nemohou si dovolit čekat na zařazení do hlavní řady, když mají jít produkty na trh. Při troše štěstí už by nejhorší dny forku, který způsobil spoustu náročných debat a zášti, měly být brzy za námi.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej: