Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
sudo-rs, tj. sudo a su přepsáné do programovacího jazyka Rust, nahradí v Ubuntu 25.10 klasické sudo. V plánu je také přechod od klasických coreutils k uutils coreutils napsaných v Rustu.
Fedora se stala oficiální distribucí WSL (Windows Subsystem for Linux).
Společnost IBM představila server IBM LinuxONE Emperor 5 poháněný procesorem IBM Telum II.
Byla vydána verze 4.0 multiplatformního integrovaného vývojového prostředí (IDE) pro rychlý vývoj aplikaci (RAD) ve Free Pascalu Lazarus (Wikipedie). Přehled novinek v poznámkách k vydání. Využíván je Free Pascal Compiler (FPC) 3.2.2.
Podpora Windows 10 končí 14. října 2025. Připravovaná kampaň Konec desítek (End of 10) může uživatelům pomoci s přechodem na Linux.
Již tuto středu proběhne 50. Virtuální Bastlírna, tedy dle římského číslování L. Bude L značit velikost, tedy více diskutujících než obvykle, či délku, neboť díky svátku lze diskutovat dlouho do noci? Bude i příští Virtuální Bastlírna virtuální nebo reálná? Nejen to se dozvíte, když dorazíte na diskuzní večer o elektronice, softwaru, ale technice obecně, který si můžete představit jako virtuální posezení u piva spojené s učenou
… více »Český statistický úřad rozšiřuje Statistický geoportál o Datový portál GIS s otevřenými geografickými daty. Ten umožňuje stahování datových sad podle potřeb uživatelů i jejich prohlížení v mapě a přináší nové možnosti v oblasti analýzy a využití statistických dat.
Kevin Lin zkouší využívat chytré brýle Mentra při hraní na piano. Vytváří aplikaci AugmentedChords, pomocí které si do brýlí posílá notový zápis (YouTube). Uvnitř brýlí běží AugmentOS (GitHub), tj. open source operační systém pro chytré brýle.
Aktuální vývojová verze jádra je 3.4-rc6 vydaná 6. května. Další týden a další -rc; myslím, že se blížíme ke konečné verzi. Tudíž prosím o testování.
Stabilní aktualizace: verze 3.0.31 a 3.3.5 vyšly 7. května s obvyklou kupou důležitých oprav.
Aktualizace 3.2.17 se 167 opravami se nyní reviduje a její vydání se dá očekávat 11. května nebo později.
Takže [KERNEL_CONT] je jako defibrilátor: je dobré ho *mít*, ale je opravdu špatné muset ho *použít*.
Mám opravdu rád pohádky, ale ne když jde o jaderný kód.
Honem! Všichni rychle řekněte něco šíleného pro Citáty týdne v dalších Jaderných novinách!
-- Jon Masters (pozor: výsledky jsou zklamáním)
Rozmanitost architektury ARM je jednou z jejích největších předností: výrobci dokázali vytvořit širokou škálu zajímavých zařízení typu system-on-chip nad běžným procesorem ARM. Jenže tato rozmanitost v kombinaci s omezenými možnostmi detekce hardwaru způsobují, že je těžké ARM v jádře podporovat. Aktuálně je nutné pro každý konkrétní systém vytvářet speciální jádro. U většiny jiných architektur je možné podporovat většinu nebo všechny systémy pomocí jediného binárního jádra (nebo možná pomocí dvou, jednoho 32bitového a jednoho 64bitového). Ve světě ARMu nic jako jediné binární jádro, které běží všude, neexistuje. Na zlepšení situace se pracuje, ale v průběhu prací je třeba dělat zajímavá rozhodnutí.
Na systému x86 je jádro z drtivé většiny schopné bootovat a dotazovat se hardwaru, aby zaslal svůj vlastní popis; jádra se tedy dokážou sama konfigurovat pro konkrétní systém, na jakém běží. Ve světě ARMu hardware obvykle takové schopnosti nemá, takže je proto jádru nutné říci, jaká zařízení jsou přítomna a kde je možné je najít. Obvykle tato konfigurace byla uložena v tzv. "board files" [soubory s definicemi pro konkrétní typ desky], která plní řadu úkolů:
Ve stromu pro architekturu ARM jsou aktuálně stovky těchto board files; neznámé množství takových souborů se nachází přímo na zařízeních a ty se do jádra nikdy nedostaly. V rámci typu platformy (konkrétní řada system-on-chip daného výrobce) je často možné umístit vícero board files do jediného jádra s tím, že konkrétní typ stroje se určuje při bootu. Ale kombinování board files napříč různými typy platforem obecně možné není.
Jedním z cílů současného pracovního zápalu ve stromu pro ARM je umožnit tvorbu multiplatformních jader. Důležitým krokem v tomto směru je pokud možno zbavit se board files; ty jsou nahrazovány pomocí stromů zařízení. Board file je nakonec jen převážně statická datová struktura popisující topologii systému; tato datová struktura se může nacházet v textovém souboru předávaném jádru přes zavaděč. Přesunutím nastavení hardwaru z jádra umožňí vývojáři ARMu použití jádra na širší řadě hardwaru. Než se dopracujeme ke skutečné multiplatformní podpoře, tak se toho bude muset ještě hodně udělat - například jde o práci na náležité abstrakci přerušení a hodin - strom zařízení ale představuje důležitý krok.
Arnd Bergmann se nedávno ostatních vývojářů zeptal, jestli má smysl v multiplatformních jádrech podporovat staré (legacy) board files. Nebo jestli by bylo lepší omezit podporu jen na systémy, které používají stromy zařízení pro enumeraci hardwaru. Arnd dal jasně najevo, jaký názor má on sám:
Můj názor je ten, že bychom u multiplatformních jader měli vyžadovat boot se stromem zařízení, protože to značně omezuje kombinatorický prostor při kompilaci, vyhýbáme se tak spoustě starých board files, které stejně nemůžeme otestovat, omezíme tím velikost jádra a budeme tak lidi motivovat k tomu, aby začali používat stromy zařízení u existujícího hardwaru.
Proti tomuto nápadu se postavilo až překvapivě hodně lidí. Někteří vývojáři to zjevně pochopili tak, že Arnd chce zahodit podporu systémů, které nemají podporu stromů zařízení, ale o to tu vůbec nejde. Současná sestavení pro jedinou platformu budou fungovat jako doposud; nikdo s tím nic dělat nebude. Smyslem je ale ulehčit život vývojářům, kteří chtějí rozchodit multiplatformní sestavení; multiplatformní jádra na ARMu nikdy nefungovala, takže vyloučení některých systémů jejich uživatele určitě neošidí o něco, co už v minulosti měli.
Někteří lidé to vnímali jako nahodilé omezení bez technického odůvodnění. Nic nestojí v cestě zahrnutí systémů bez stromu zařízení v multiplatformním jádře, až na dodatečnou složitost a balast, který je s tím spojen. Jenže složitost a balast jsou technické problémy, zejména když je řešený problém už tak sám o sobě dost složitý. Bylo rovněž poukázáno na to, že tu máme starší platformy, které nikdo v poslední době moc neudržuje, ale jsou i tak nadále užitečné pro uživatele.
Nakonec půjde hlavně o to, co budou uživatelé multiplatformních jader chtít. Nebylo hned zrovna jasné, že si taková jádra najdou své uživatele: jádra pro ARM jsou obvykle zacílena na konkrétní zařízení, takže přidání podpory pro jiné systémy nemá žádné výhody. Proto výrobci embedded systémů asi nebudou mít o multiplatformní jádra zájem. U distributorů je to ale něco trochu jiného; rádi by podporovali spoustu hardwaru bez nutnosti sestavovat velké množství jader. Vývojář Debianu Wookey to popsal takto:
Rádi bychom viděli multiplatformní jádra, protože muset jich sestavovat obrovskou hromadu je dost nepříjemné (a nejen pro arm, protože to zdržuje bezpečnostní aktualizace) a pokud bychom to mohli pokrýt jediným jádrem, nebo samozřejmě méně než 7 jádry, tak by to bylo super.
V jedné z reakcí Arnd změnil svůj návrh, umožnil používání board files u podarchitektur, u kterých je nepravděpodobné, že budou v blízké budoucnosti podporovat stromy zařízení. V ten moment se diskuze uklidnila bez jakéhokoliv formálního zakončení. Toto téma bude pravděpodobně diskutováno na blížícím se Linaro Connect a dost možná i ještě potom. Je tu ještě řada dalších problémů, které se musí vyřešit, než se multiplatformní jádra pro ARM stanou realitou; to znamená, že je dostatek času na správné rozhodnutí, ke kterému se dospěje po zvážení všech relevantních potřeb.
Při vydání předverze 3.4-rc6 dal Linus vědět, že konečné vydání 3.4 asi nebude daleko. To znamená jediné: je čas podívat se na statistiku tohoto vývojového ckylu. 3.4 byl dosti živý cyklus s překvapeními.
V době psaní tohoto textu Linus začlenil přes 10 700 změn do verze 3.4; tyto změny pocházejí od 1259 vývojářů. Celkový nárůst velikosti jádra je tentokrát kolem 215 000 řádek. Nejaktivnějšími vývojáři tohoto cyklu byli:
Nejaktivnější vývojáři cyklu 3.4 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Mark Brown se nachází na vrcholu přispěvatelů už podruhé v řadě; jako obvykle odvedl spoustu práce kolem zvukových ovladačů a souvisejících subsystémů. Russell King je hlavním správcem ARM; aktivně se účastnil refaktorování a pročišťování kódu pro architekturu ARM. Johannes Berg nadále pracuje na vrstvě mac80211 a ovladači iwlwifi, Al Viro vylepšuje VFS API a opravuje chyby napříč jádrem a Axel Lin dělá spoustu pročišťování v ALSA a regulačních subsystémech.
Joe Perches vede v počtu změněných řádek díky opravám ve stylu kódu, změnám v pr_*() a souvisejícím věcem. Dan Magenheimer přidal mechanismus sdílení paměti "ramsterů do stromu staging. Údržbář Linux-next Stephen Rothwell se dostal do přehledu změněných řádek díky odstranění spousty starého kódu pro PowerPC. Greg Kroah-Hartman pracuje napříč stromem, ale většinu jeho práce najdeme ve stromu staging.
Do vývojového cyklu 3.4 přispělo nějakých 195 firem. Těmi nej tentokrát byly:
Nejaktivnější zaměstnavatelé v 3.4 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
Stálicí v této tabulce je Red Hat jako nejlepší korporátní přispěvatel; ve verzi 3.4 byl ale Red Hat vytlačen Intelem. Příspěvky Red Hatu poklesly; ve verzi 3.4 jde jen o 960 sad změn v porovnání s 1290 ve verzi 3.3. Větší změnou je ale nárůst aktivity u Intelu. Jde hlavně o podporu pro hardware Intelu, ale jde i o věci, jako je podpora x32 ABI. Texas Instruments se nadále posouvají vzhůru stejně jako řada jiných společností kolem mobilních a embedded zařízení. Dříve se říkalo, že vývoji Linuxu vládnou velké korporace orientované na enterprise; tyto společnosti nikam nezmizely, ale už nejsou jediným tahounem. Příspěvků od dobrovolníků je podle trvajícího trendu opět méně než kdy předtím.
V posledních vývojových cyklech bylo možné vidět spoustu práce na stromu ARM a verze 3.4 není výjimkou; tentokrát je to 1100 sad změn v arch/arm. Tyto změny pocházejí od 178 vývojářů, kteří zastupují 51 firem. Mezi těmito firmami byly nejaktivnější tyto:
Nejaktivnější zaměstnavatelé v 3.4 (strom ARM) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
ARM je jednoznačně místem, kde je spousta aktivních konzultantů; ti tentokrát přispěli více než 13 % změn. Jinak se v této oblasti nekonají žádná překvpení.
Na vývoj pro ARM se dá ale dívat i trochu jinak. Mnoho práce na ARM je děláno skrze konzorcium Linaro. Mnoho vývojářů, kteří přispívají z adresy linaro.com, jsou "najatí" z jiných firem; v této tabulce je co nejvíce práce přiřknuto skutečného zaměstnavateli, který za práci zaplatil. Kdyby ale všechno z adresy Linaro bylo na řádku Linaro, tak by právě Linaru patřilo 11,9 % všech změn v arch/arm, což by z něj dělalo hlavního zaměstnavatele, i když by počet změn byl stále měnší než od nezávislých konzultantů. Linaro se evidentně stalo důležitou součástí vývojářské komunity pro ARM.
Suma sumárum, šlo o další rušný a produktivní vývojový cyklus. Navzdory obvyklým zásekům se věci stabilizují a je tedy dost možné, že 3.4-rc7 bude poslední předverzí, takže tento cyklus by měl být celkem krátký. Jaderní vývojáři si ale moc neodpočinou; cyklus verze 3.5 se zběsilým začleňovacím oknem začne zanedlouho.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Vzhledem k tomu, že v (druhé) odpovědi od Dana Williamse je i id commitu, není zase až tak těžké si to zjistit.Rád se nechám poučit. S tím ID commitu jsem to právě chtěl najít a nepovedlo se mi to. Poradíš postup?
Pokud je k dispozici naklonovaný Linusův git, tak např. pomocí
git describe --contains e35f30c1
Momentálně to napíše "fatal: cannot describe ...
", příští týden (?) už by to mělo ukázat něco, co bude začínat "v3.5-rc1-", kdyby byl commit ve 3.4, byl by na začátku odpovídající tag.
Přes webové rozhraní mne nic elegantního nenapadá, ale fungovalo by např. najít si ten commit, kliknout si na odkaz "commitdiff", pak si z hlavní stránky kliknout na tag v3.4
, pak na "tree" a podívat se na některý ze souborů, které commit mění, jestli je tam patch aplikovaný nebo ne.
Pokud je k dispozici naklonovaný Linusův git, tak např. pomocíTahle informace mi jaksi chyběla. Já jsem totiž vůbec netušil, jestli to v Linusově gitu bude (a v tu chvíli mi to nestálo za stahování), když to ještě vůbec není zařazeno.
Momentálně to napíše "fatal: cannot describe ...", příští týden (?) už by to mělo ukázat něco, co bude začínat "v3.5-rc1-", kdyby byl commit ve 3.4, byl by na začátku odpovídající tag.Aha. Myslel jsem, že byl můj dotaz srozumitelný, ale jak vidím, tak jsem se měl napsat, že chci funkční postup a nepředpokládat, že je to zřejmé.
není zase až tak těžké si to zjistit.Tedy ještě jednou. Rád bych k téhle velkohubé větě dostal i jeden funkční postup.
Přes webové rozhraní mne nic elegantního nenapadá, ale fungovalo by např. najít si ten commitMně je jedno jestli přes webové rozhraní nebo příkazovou řádku. Stačí mi jeden funkční obecný postup na nalezení commitu, o kterém se píše na mailing listu. Když sám píšeš, že to není až tak těžké. Kdybych věděl, že budeš odpovídat totální nesmysly, budu se ptát jinde, že.
v3.4
") jasné, že ten commit ve verzi 3.4 není.
Ale to je přece správně.Správně ano, jen je to odpověď na jinou otázku :). Viz níže.
Aha. Myslel jsem, že byl můj dotaz srozumitelný, ale jak vidím, tak jsem se měl napsat, že chci funkční postup a nepředpokládat, že je to zřejmé.
Co je na tom postupu konkrétně nefunkčního? Mně dává přesně takový výsledek, jaký dávat má.
Tedy ještě jednou. Rád bych k téhle velkohubé větě dostal i jeden funkční postup.
Uvedl jsem dva.
Mně je jedno jestli přes webové rozhraní nebo příkazovou řádku. Stačí mi jeden funkční obecný postup na nalezení commitu, o kterém se píše na mailing listu.
Ve webovém rozhraní je možné vyhledávat podle subjectu nebo autora. Podle hashe bohužel ne, ale to lze triviální obejít tak, že si zobrazím jakýkoli náhodně vybraný commit a přepíšu hash v URL.
Jako bonus ještě přidám zlepšovák pro Firefox:
%s
" (bez uvozovek)Kdybych věděl, že budeš odpovídat totální nesmysly, budu se ptát jinde, že.
Kdybych měl šanci uhodnout, že chcete vědět něco jiného (jak najdu commit X), než na co se ptáte (jak zjistím, je-li commit X obsažen v release Y), tak bych odpovídal rovnou. Křišťálové koule nemaje, odpovíděl jsem na dotaz, který byl položen.
Kdybych měl šanci uhodnout, že chcete vědět něco jiného (jak najdu commit X), než na co se ptáte (jak zjistím, je-li commit X obsažen v release Y)Já se ptal pouze na replikaci tvého zjištění, že commit e35f30c1 bude v release 3.5.
Křišťálové koule nemaje, odpovíděl jsem na dotaz, který byl položen.Byl bych potěšen, kdyby tomu tak bylo.
Já se ptal pouze na replikaci tvého zjištění, že commit e35f30c1 bude v release 3.5.
Nelze samozřejmě zcela stoprocentně vyloučit, že Linus ten patch z nějakého důvodu revertne. Ale jelikož už v gitu je, tak pokud se tak nestane, tak prostě v 3.5 bude.
Byl bych potěšen, kdyby tomu tak bylo.
Ufff… Tak ještě jednou: zeptá-li se mne někdo, zda je něco v jádře 3.4, já mu odpovím že ne a on na to, jak to zjistit, pak prostě z kontextu předpokládám, že se ptá na to, jak zjistí, že v jádře 3.4 to není. To, že je-li patch v gitu a není v poslední dosud vydané verzi, pak bude v nejbližší vydané verzi (pokud ho někdo nerevertne, Linus se nerozhodne místo 3.5 vydat verzi 4, nenastane konec světa atd.), jsem prostě považoval za znalost, kterou lze v diskusi k Jaderným novinám předpokládat.
Dan Williams uvedl pouze hash, který může mít commit v jakémkolik gitovském repozitáři v jakékoli větvi, což by měl vědět průměrný uživatel Gitu.
Pokud mne nějaká chyba nebo feature zajímá natolik, že se na ni zeptám v netdev listu, a dostanu odpověď "řeší to commit X" (bez určení repozitáře), tak se nejdřív podívám, jestli to není v tom hlavním Linusově, případně dalších, které by připadaly v úvahu (v tomto případě net a net-next Davea Millera). A když to nebude ani v jednom, tak se holt zeptám.
Naposledy: odpověděl jsem na otázku, která byla položena. Hluboce a poníženě se tedy omlouvám vašemu blahorodí, že jsem si dovolil neuhodnout, co ráčilo vědět, a místo toho přízemně odpověděl na to, na co se ptalo. Slibuji, že už to víckrát neudělám a radši vám nebudu odpovídat vůbec, abych se podobného faux pas nedopustil znovu.
Howgh.
?board files? … Než se dopracujeme ke skutečné multiplatformní podpoře, tak se toho bude muset ještě hodně udělat ? například jde o práci na náležité abstrakci přerušení a hodin ? strom zařízení ale představuje důležitý krok.Asi se někde poztrácely české uvozovky a pomlčky, jsou místo nich otazníky. Zkoušel jsem Chrome a Firefox, v obou je to stejné, takž eto nevypadá na problém v přijímači.
jsou ?najatí? z jiných direm