Byla vydána (Mastodon, 𝕏) vývojová verze 3.1.4 příští stabilní verze 3.2 svobodné aplikace pro úpravu a vytváření rastrové grafiky GIMP (GNU Image Manipulation Program). Přehled novinek v oznámení o vydání.
Zakladatel ChimeraOS představil další linuxovou distribuci zaměřenou na hráče počítačových her. Kazeta je linuxová distribuce inspirována herními konzolemi z 90. let. Pro hraní hry je potřeba vložit paměťové médium s danou hrou. Doporučeny jsou SD karty.
Komunita kolem Linuxu From Scratch (LFS) vydala Linux From Scratch 12.4 a Linux From Scratch 12.4 se systemd. Nové verze knih s návody na instalaci vlastního linuxového systému ze zdrojových kódů přichází s Glibc 2.42, Binutils 2.45 a Linuxem 6.15.1. Současně bylo oznámeno vydání verze 12.4 knih Beyond Linux From Scratch (BLFS) a Beyond Linux From Scratch se systemd.
Organizátoři konference LinuxDays ukončili veřejné přihlašování přednášek. Teď je na vás, abyste vybrali nejlepší témata, která na letošní konferenci zaznějí. Hlasovat můžete do neděle 7. září. Poté podle výsledků hlasování organizátoři sestaví program pro letošní ročník. Konference proběhne 4. a 5. října v Praze.
Byla vydána verze 11.0.0 vizuálního programovacího jazyka Snap! (Wikipedie) inspirovaného jazykem Scratch (Wikipedie). Přehled novinek na GitHubu.
Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.
Wayfire, kompozitní správce oken běžící nad Waylandem a využívající wlroots, byl vydán ve verzi 0.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Videoukázky na YouTube.
Před necelými čtyřmi měsíci byl Steven Deobald jmenován novým výkonným ředitelem GNOME Foundation. Včera skončil, protože "nebyl pro tuto roli v tento čas ten pravý".
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.
Současné vývojové jádro je 2.6.37-rc2 vydané 15. listopadu. A všechno vypadá tak, jak rád vidím, když -rc2 vypadá: není tam nic zajímavého. Většinou obsahuje opravy, ale také nějaké zbytky práce na odstranění velkého jaderného zámku, konečné odstranění podpory tvrdých bariér z blokové vrstvy a pár nových LED ovladačů. Detaily vizte v kompletním changelogu.
Po vydání -rc2 byla začleněna významná změna API ovladačů: funkce ze střední vrstvy [midlayer] SCSI queuecommand() se nyní volá bez zámku hostitele; prototyp funkce se změnil také.
Stabilní aktualizace: žádné nevyšly od 29. října.
-- Rusty Russel
-- Ingo Molnár
napsal Jonathan Corbet, 17 listopadu 2010
Souborové systémy XFS a OCFS2 v současnosti mají možnost „vyrazit do souboru díru“, tedy označit část souboru jako nepotřebnou, takže se s ní spojený úložný prostor uvolní. Josef Bacik usoudil, že tato vlastnost by mohla být v blízké budoucnosti přidána do ostatních souborových systémů, takže by jádro pro vyrážení děr mělo nabízet standardní rozhraní. Výsledkem je rozšíření systémového volání fallocate(), které tuto možnost přidává.
Konkrétně patch přidává nový příznak (FALLOC_FL_PUNCH_HOLE), který systémové volání rozpozná. Pokud souborový systém je schopen danou operaci provést, daný rozsah dat bude ze souboru odstraněn; jinak se vrátí ENOTSUPP. Současná implementace nezmění velikost souboru; jestliže budou „vyraženy“ bloky na konci souboru, soubor si zachová stejnou velikost. Trochu se diskutovalo nad tím, jestli by měla být změna velikosti souboru podporována, ale zdá se, že v současnosti je konsenzus takový, že by to přineslo víc problémů, než vyřešilo.
napsal Jonathan Corbet, 17 listopadu 2010
Dokud budeme mít desktopové systémy, budou se téměř určitě řešit záležitosti ohledně jejich interaktivity. Během let přišlo a odešlo mnoho komplexních schémat pro zlepšení interaktivity; u většiny z nich byla přinejmenším část uživatelů nespokojená. Zázračné léky se shánějí těžko, ale zdá se, že nedávný patch se k tomu přiblížil... přinejmenším pro některé uživatele. Zajímavé je, že je to konceptuálně tak jednoduché řešení, že možná ani nebude muset být v jádře.
Základní myšlenka zcela férového plánovače [CFS, completely fair scheduler] je jeho naprostá férovost: jestliže o CPU soupeří N procesů se stejnou prioritou, pak každý dostane 1/N dostupného času CPU. Tato politika nahradila poměrně komplikované heuristiky „interaktivity“, které najdeme v plánovači O(1); ve většině situací na desktopu podává lepší výsledky. Tento přístup nicméně v některých situacích selže. Jestliže uživatel spustí deset instancí překladače pomocí make -j 10 společně s aplikací pro přehrávání videa, každý proces dostane „férových“ 9% CPU. Těchto 9% nemusí stačit na to, aby si uživatel užil video tak, jak by chtěl. Není tedy překvapením, že většina uživatelů „férovost“ vidí jinak; nebylo by hezké, kdyby překlad jako celek dostal 50% a přehrávání videa druhou polovinu?
Jádro je schopné zajistit tuto férovost již léta pomocí skupinového plánovače. Sada procesů vložená do jedné skupiny dostane férový podíl na času CPU přiděleného celé skupině, ale skupiny samy budou soupeřit o férový podíl na CPU. Takže pokud bude přehrávač videa vložen do jedné skupiny a překlad do jiné, pak každá dostane polovinu dostupného času CPU. Různé procesy pracující na překladu potom dostanou férový podíl na polovině, která patří jejich skupině; budou soupeřit samy mezi sebou, ale ne s přehrávačem videa. Toto nastavení zajistí, že přehrávač dostane čas CPU, aby stíhal zpracovávat proud dat a plnit všechny požadavky na interaktivitu.
Skupiny jsou tedy hezkou vlastností, ale od doby, kdy byly v 2.6.24 začleněny, se příliš nepoužívaly. Důvody jsou jasné: pro nastavení vyžadují práci administrátora a oprávnění superuživatele; většina uživatelů neví, jak je vyladit a nechtějí se to učit. Co celé ty roky chybělo, je zajistit, aby skupinové plánování pro běžné uživatele „prostě fungovalo“. To je cílem patche pro skupinové plánování podle TTY, jehož autorem je Mike Galbraith.
V krátkosti tento patch automaticky vytvoří skupinu spojenou s každým TTY v systému. Všechny procesy, jejichž řídícím terminálem je dané TTY, budou vloženy do odpovídající skupiny; kód skupinového plánování potom může sdílet čas mezi skupinami procesů podle jejich řídících terminálů. Překlad je obvykle zahájen příkazem „make“ v okně emulátoru terminálu; tato úloha bude mít jiný řídící TTY než přehrávač videa, který nemusí mít žádný řídící TTY. Výsledkem tedy je, že seskupování podle TTY automaticky oddělí úlohy spuštěné v terminálech od úloh spuštěných pomocí správce oken.
Z tohoto chování je Linus šťastný; Linus je koneckonců přesně ten druh člověka, který by mohl do čekání na vysoce paralelní kompilaci jádra propašovat jedno rychlé video. Řekl:
Ostatní také nahlásili významné zlepšení odezvy desktopu, takže tato vlastnost vypadá jako jedna z těch, která má nadprůměrné šance dostat se v příštím začleňovacím okně do hlavní řady. Je tu nicméně několik nesouhlasných hlasů, přičemž většina z nich si myslí, že TTY je špatný ukazatel pro to, do které skupiny proces umístit.
Nejotevřenější – jako to obvykle bývá – je Lennart Poettering, který prohlásil, že spojit něco takového s TTY je prostě praštěné; raději by viděl něco, co je založené na sezeních [sessions]. A, jak řekl, tohle by bylo lepší udělat v uživatelském prostoru. Linuse to, když to řekneme slušně, neohromilo, ale Lennart opětoval palbu několika řádky v bashi, které dosáhnou stejných výsledků jako Mikeův patch – bez nutnosti jakkoliv patchovat jádro. Ukazuje se, že práce s řídícími skupinami není tak těžká.
Linusovi se nicméně stále líbí jaderná verze, hlavně protože může „prostě fungovat“ bez jakéhokoliv zásahu uživatele:
Jinými slovy zlepšení, které se prostě objeví s jádrem, bude pravděpodobně k dispozici více uživatelům, než něco, co vyžaduje, aby každý uživatel udělal (jednorázovou) ruční změnu.
Lennart nesouhlasí. Skutečné řešení v uživatelském prostoru, říká, nebude znamenat, že si uživatelé budou muset editovat svoje .bashrc; také bude mít podobu „prostě funguje“. Mělo by to přijít jako malé překvapení v podobě, kterou si představuje v systemd; zdá se, že v budoucnu se plánuje, že systemd převezme správu sezení; v tom okamžiku bude snadné založit skupinové plánování právě na sezení. Lennart věří, že toto řešení bude flexibilnější; bude moci seskupovat procesy způsobem, který dává pro „běžné uživatele desktopů“ větší smysl než seskupování založené na TTY. Také se kvůli tomu nebude muset aktualizovat jádro.
Další nápad, který byl navržen, je přidat pro desktopové spouštěče aplikací možnost „spustit v samostatné skupině“, což by uživateli snadno umožnilo mít kontrolu nad tím, jak se budou aplikace dělit.
Linus podle všeho neustupuje od jaderné verze patche:
Příští začleňovací okno lze nicméně očekávat až v lednu; to je docela slušné množství času, aby lidé demonstrovali jiné přístupy. Jestliže se řešení v uživatelském prostoru ukáže jako flexibilnější a v dlouhodobém měřítku efektivnější, stále může vyhrát. To platí obzvláště proto, že začlenění Mikeova patche nijak nepřekáží řešením v uživatelském prostoru; jestliže přístup založený na systemd předvede lepší výsledky, distributoři se jej mohou rozhodnout používat. Tak jako tak se zdá, že lepší interaktivní odezva se objeví v blízké budoucnosti.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Vyvíjí se vůbec POSIX co se API systému týče?Pokud vím, tak minimálně.
Myslím si, že by prvotní iniciativa měla jít odtud. Když vidím věci jako epoll / kqueue / /dev/poll, tak si říkám, že unixu chybí standardizace a pak si každý unix dělá, co chce a kdy chce.Tak ona standardizace (a hlavně unifikace) unixového API byla vždycky spíše dodatečná. Oblíbená nestandardní rozšíření se postupně dostávala do standardnu. A já si myslím, že to není špatná cesta. Podle mě je ideálním standardem pro rozhraní operačního systému jen kratičký text, ve kterém se nachází seznam odkazů na dílčí standardy, které je třeba podporovat, aby se člověk mohl hlásit k podpoře standardu. Podporuje to možnost rozdělení práce a nevznikají tisícistránkové dokumenty. A zrovna přístupová práva jsou v POSIXu stále stejná (draft ACL můžeme s klidem zanedbat jako nestandardní a nedotažený). Ono je zajímavé, že na poli ACL jsou na tom oproti Linuxu už líp i windows (a tuším i MacOSX a Solaris, ale nezkoumal jsem detailně). Jediné, co vidím jako šanci na nápravu je NFSv4 ACL zavedené do běžných filesystémů.
Přidám něco z pozdějších "novinek" na lkml:
Linus je dost tvrdohlavý na to, aby jadernou verzi autogroup scheduleru protlačil do hlavní řady. Ospravedlňuje to tím, že jde v podstatě "jen o heuristiku, kterou jde vypnout". Mike mu taky nahrál čtvrtou verzí patche, která staví na SID (session id) místo TTY.
Podle mě Lennartova pointa taky není špatná - je hodně těžké rozlišit, které aplikace potřebují svoji groupu a které ne. IMHO to z kernelu prakticky nejde poznat. Tím se logicky dostáváme do userspace, který by měl nějak kernelu napovídat. Současný cgroups interface je moc odporný a "generic" na tento typ úlohy, takže tipuji, že ve výsledku dojde jak na patch na straně kernelu, který bude dělat něco málo a navíc přidávat několik sysfs položek, pomocí kterých bude moci userspace snadno ručně "dolazovat" to, co heuristika nezvládla, tak na userspace "patch".
Starý dobrák Con Kolivas se taky vyjádřil a podle mě dobře. Ač byla některá jeho tvrzení vyvrácena / zpochybněna, jeho "latnice" tunable nemusí být až tak špatný nápad. Minimálně naznačuje, že kernel si bez nápověd z userspace moc neporadí, což opět směřuje k tomu sysfs interface.
Závěrem snad jen to, že z group scheduling se stala mediální bublina - v běžném workloadu běžného desktop usera nepomůže prakticky vůbec. Pomůže v Linusově případě make -j64
, pomůže v případech programů s tunou forků / vláken, které by mohly prakticky ovlivnit jiné uživatelem přímo používané aplikace, ale takových případů není moc.
Osobně vidím daleko větší problém v I/O scheduleru - v současné době si nemůžu pustit video ve vlc, pokud něco kopíruji z disku na disk, ani nice
, ani ionice
nepomůže, video se bude pořád zasekávat. To mi přijde jako daleko větší problém, než make -j64
. A ne, group scheduling tomu jednomu cp
procesu s jedním vláknem nepomůže.
On je problém v té propustnosti. Čistě teoreticky by skutečně "kompletně" férový plánovač (CFQ) měl férově rozdělovat přístup k disku rovnoměrně (ne podle počtu přenesených dat, ale podle I/O time), tedy přehrávač by neměl mít problém načíst jednou za 10 sekund 400KB dat, pokud na pozadí kopíruje dd
rychlostí 130MB/s.
Někde ale scheduler selhal - tedy on se spíš snaží udržet vysokou propustnost a co nejlépe využít cache, takže místo toho, aby jednou za 10 sekund umožnil okamžitý přístup přehrávači, tak požadavek na čtení zařadí a bude doufat, že v dohledné době někdo jiný přečte ten stejný sektor, aby ho plánovač nemusel číst dvakrát, kdy bude hlava nejbllíž, zda mezitím "ten druhý" nedokončí současnou operaci, apod. Pochopitelně po celou tu dobu požadavek na čtení od přehrávače stagnuje, což pak způsobí zásek v přehrávání a to nechutné rozmazání obrazu kvůli chybějícímu klíčovému snímku v okamžiku zamrznutí.
Částečně to měl řešit low_latency tunable přidaný někdy kolem 2.6.32 (tak nějak), který mimojiné resetuje i zápisové NCQ operace, ale ten tu mám jako "1" defaultně a relativně beze změny.
Pokud se to v 2.6.37 nezlepší, asi zkusím BFQ, mám to v TODO listu už nějak dlouho.
Závěrem snad jen to, že z group scheduling se stala mediální bublina - v běžném workloadu běžného desktop usera nepomůže prakticky vůbec.Myslim, ze nikdy nebylo obecne tvrzeno, ze by group scheduling mel pomoci workloadu bezneho desktop usera. Jeho aplikace jsou uplne jine.
2.6.24 si pamatuju - před ním boinc spotřebovával čas CPU jenom, když mu něco zbylo (takže nezdržoval ostatní aplikace).K tomuhle by měla sloužit IDLE priority, bohužel na Linuxu vidím tohle jen u I/O. Fakt není nic takového na CPU?
Není tedy překvapením, že většina uživatelů „férovost“ vidí jinak; nebylo by hezké, kdyby překlad jako celek dostal 50% a přehrávání videa druhou polovinu?No a ta zmíněná priorita procesu je na co?
/dev/kristalova-koule
taky ne.Mi přijde, že tady by měl někdo Cimrmanovsky říct "Tudy ne, přátelé"Mě z článku přišlo, že se lidi snaží, ale Linusovi ruplo v kouli.
watchdog má realtime,watchdogd s realtime prioritou? Dekuji nechci. To by totiz znamenalo, ze kdyz se ti tam neco zblazni a vytizi system takovym zpusobem, ze nic ostatniho nefunguje a nejde se tam prihlasit, tak watchdogd porad odpovida a system se nerestartuje.