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.
Jarní konference EurOpen.cz 2025 proběhne 26. až 28. května v Brandýse nad Labem. Věnována je programovacím jazykům, vývoji softwaru a programovacím technikám.
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.
Před 25 lety zaplavil celý svět virus ILOVEYOU. Virus se šířil e-mailem, jenž nesl přílohu s názvem I Love You. Příjemci, zvědavému, kdo se do něj zamiloval, pak program spuštěný otevřením přílohy načetl z adresáře e-mailové adresy a na ně pak „milostný vzkaz“ poslal dál. Škody vznikaly jak zahlcením e-mailových serverů, tak i druhou činností viru, kterou bylo přemazání souborů uložených v napadeném počítači.
Byla vydána nová major verze 5.0.0 svobodného multiplatformního nástroje BleachBit (GitHub, Wikipedie) určeného především k efektivnímu čištění disku od nepotřebných souborů.
Na čem pracují vývojáři webového prohlížeče Ladybird (GitHub)? Byl publikován přehled vývoje za duben (YouTube).
Aktuální verze jádra je 2.6.16. Vydána 19. března. Od 2.6.16-rc6 bylo začleněno poměrně dost oprav, ale nic zásadního. Pro ty z vás, kdo dění moc nesledují: mezi velké, pro uživatele patrné změny patří clusterový souborový systém OCFS2, několik síťovacích změn, včetně kontroly zahlcení CUBIC, podpory TIPC a IPv6 verze DCCP, migrace swapu a patche pro přímou migraci, nové třídy scheduleru [plánovače] SCHED_BATCH, pár nových systémových volání pro souborové systémy a kódu pro detekci a opravu chyb. Velké interní změny zahrnují změnu na mutex a kód časovače s vysokým rozlišením. Podrobnosti najdete v dlouhém changelogu.
Git repozitář hlavního stromu obsahuje velkou hromadu patchů začleněných do 2.6.17-rc1; vizte shrnutí níže.
Aktuální -mm strom je 2.6.16-rc6-mm2. V poslední době byl v -mm reorganizován kód migrace stránek (mezitím už byl začleněn), bylo provedeno pár změn v časovavačích s vysokým rozlišením, vylepšen scheduler a přidány patche předělávající MD RAID.
Já jen vynucuji pěkné chování pod hrozbou pevného lana. Jeden konec připevním k balvanu, druhý na krk úlohy. Úloha se sama rozhodne, jestli bude oběšena, a uživatel rozhoduje o délce lana.
-- Mike Galbraith. Kdo říká, že je těžké porozumět patchům pro scheduler?
Jak už bylo slibováno dříve, OSDL oznámila vytvoření "technického poradního panelu", který má pomáhat se zlepšováním vztahů s vývojářskou komunitou kolem linuxového jádra. Prvními členy jsou James Bottomley, Wim Coekaerts, Randy Dunlap, Greg Kroah-Hartman, Christoph Lameter, Matt Mackall, Theodore Ts'o, Arjan van de Ven a Chris Wright.
Proces začleňování patchů do hlavního stromu pro 2.6.17 již probíhá několik dní. Bylo zařazeno kolem 1500 patchů, i když počet viditelných změn je relativně nízký. Zatím se do jádra dostalo toto:
Jedním z mnoha nových systémových volání přidaných do jádra 2.6.16 je unshare(). Jeho účelem je dělat opak toho, co dělají různé sdílecí [sharing] parametry [flags] clone(): používá se k odpojení některých zdrojů procesu od zdrojů jeho předků a sourozenců. S unshare() může proces požádat o své vlastní souborové systémy, jmenné prostory nebo tabulku popisovače souboru. "Odsdílení" [unsharing] dalších zdrojů, včetně undo informací semaforů, virtuální paměti, obsluhovačů signálů atd. je plánováno pro budoucí verze.
Těsně před finálním vydáním 2.6.16 se objevilo pár otázek ohledně unshare(); jen některé z těchto otázek byly ve výsledném jádře dořešeny.
Jedna z nich se týkala implementace unshare(CLONE_VM), která způsobuje, že volající proces přestane sdílet paměť s ostatními. Zdálo se, že tato funkčnost je hotová a kompletní, ale Oleg Nesterov si všiml, že kód nebere v potaz možnost, že by hlavní část adresného prostoru mohla být v procesu. Řešením je prozatím zakázání odsdílení paměti. Vypadá to, že není nikdo, kdo by tuto funkci rychle potřeboval, a už bylo příliš pozdě na pokusy o opravu funkce spravující hlavní paměť.
Eric Biederman vznesl několik otázek týkajících se API unshare(), které by byl rád opravil dříve, než se stane součástí vydaného jádra. Jedním z problémů bylo použití stejné sady parametrů jako používá clone() pro specifikaci sdílení. Eric tvrdí:
sys_unshare neumí implementovat ani polovinu parametrů clone a ty, které implementuje, mají lehce jinou sémantiku než u clone. Použitím odlišné sady parametrů bychom naznačili, že jde o rozdílné věci.
Diskuze se příliš daleko nedostala, protože Linus dává přednost stejným parametrům a nevypadá to, že by to někoho jiného nějak extra trápilo.
Erikova další připomínka byla o tom, že unshare() nezjišťuje, zda parametry existují; prostě je tiše ignoruje. Takže si uživatelský prostor může požádat o odsdílení zdrojů, které unshare() nezná nebo nepodporuje, a nebude vrácena žádná chyba. To by mohlo v budoucnu, kdy se očekává rozšiřování sady platných parametrů pro unshare(), představovat problém. Program napsaný tak, aby využíval nové parametry, by se nemusel chovat dle očekávání, pokud by byl spuštěn na jádře 2.6.16; funkčnost, kterou bude požadovat, nebude k dispozici, ale jádro o tom nepodá zprávu.
Eric poslal patch, který řešil obě záležitosti: názvy parametrů a zjišťování platných parametrů. Nebyl však do 2.6.16 začleněn. Samotný test na známé parametry začleněn být mohl (a skutečně byl začleněn do 2.6.17), ale kombinovaný patch přijat nebyl. Andrew Morton poznamenal: "Tvůj patch dělal dvě rozdílné věci - z toho plyne poučení." Zvláště těsně před vydáním finálního jádra je důležité připravovat patche úzce zaměřené na jediný problém.
Linuxový CPU scheduler [plánovač] urazil dlouhou cestu od dob čerstvého 2.6, kdy byl příčinou nemalých starostí. Plánovací domény napravily spoustu potíží na větších systémech, zatímco celá sada heuristiky pro interaktivitu pomohla lépe fungovat desktopům. Zvláště práce s interaktivitou je založena na pojmu "průměr spánku" [sleep average]. Každý proces, který stráví hodně času spaním v poměru k času, kdy běží, je považován za "interaktivní" a je mu přidělena vyšší priorita.
Tento mechanismus funguje tak dobře, že na reakční časy současných 2.6 jader si stěžuje málokdo. Občas se však stane, že někdo přijde se zátěží, které se podaří scheduler zmást, a celý desktop zatuhne. Mike Galbraith se některými z těchto případů zabývá a připravuje patche, které by měly pomoci se zmírňováním podobných problémů.
Linuxový scheduler udržuje dvě "pole" front pro každý procesor. Každému procesu je při startu přidělen časový úsek a je zařazen do "aktivního" pole, kde může bojovat o CPU. Jakmile časový úsek vyprší, proces se přesune do "prošlého" pole, kde vyčkává, dokud všechny ostatní procesy nepoužijí své úseky. Když se všechny procesy ocitnou v prošlém poli, pole jsou prohozena a celý postup se opakuje.
V jádře 2.6 je však výjimka: proces považovaný za interaktivní (protože stráví dostatek času v přerušitelných spáncích) bude po vypršení svého časového úseku vrácen do aktivního pole. Díky tomu by neměl interaktivní proces být donucen čekat, až se nějaký dlouhotrvající dávkový proces prokouše svým časem. Aby tento mechanismus nemohl zcela zablokovat prošlé procesy, scheduler kontroluje, jestli procesy v prošlém poli nečekají příliš dlouho. Po překročení prahu "vyhladovění" jdou všechny procesy po vypršení svých časových úseků do prošlého pole, což scheduleru umožní provést prohození polí v relativně blízké budoucnosti.
Mike zjistil, že na systému, kde běží silně zatížený Apache server, mohou některé úlohy hladovět velmi dlouhou dobu; vypadá to, že mechanismus, který má bránit vyhladovění, nefunguje správně. Problém vězel v probouzecím kódu. Kód vždy dával čerstvě probuzené procesy do aktivního pole bez ohledu na to, co se dělo ve zbytku systému. Protože bylo neustále probouzeno velké množství serverových procesů díky příchozím požadavkům, scheduler se vůbec nedostal k prohození polí. Řešením bylo vložit kontrolu hladovění do __activate_task(); výsledkem je, že pokud prošlé procesy hladoví, budou procesy probouzeny do prošlého pole. Tato malá oprava se postarala o velkou část problému.
Větší opravy však byla potřeba pro patch přiškrcující úlohy, na kterém Mike už nějaký čas pracuje. Součástí této práce je několik oprav, ale základní zjištění je následující: kód, který se stará o "průměr spánku" může být příliš štědrý k procesům, které spí jen chvilku. Proces, kterému se podaří pravidelně na krátkou chvilku usnout, může výrazně zvýšit svoji prioritu. Natolik, že vytlačí ostatní procesy běžící na daném systému. A získá-li proces bonus interaktivity, může si ho nějakou dobu podržet. To vše je záměrné; některé interaktivní programy mohou velmi dlouho sedět a pak chvilku provádět náročné výpočty. Vezměte si třeba X server s tím pěkným kompozitním správcem oken; spoustu času je nečinný, jen aby procesor sešlápl, když začne uživatel tahat okna po obrazovce. Ale takové chování může také udělit prioritní bonus interaktivity procesům, které ve skutečnosti interaktivní nejsou.
Řešení zahrnuje několik změn. Jednou z nich je prostě menší štědrost při rozdělování bonusů. Ale jádrem patche je funkce nazývaná refresh_timeslice(). Tato funkce porovnává aktuální průměr spánku s časem, který proces doopravdy stráví v procesoru. Na základě tohoto srovnání je upraven škrtící čas pro každý proces. Je-li CPU používáno více než by odpovídalo průměru spánku, je čas přiškrcení posunut dozadu; jinak dopředu. Narazí-li proces na čas přiškrcení, začne jeho průměr spánku rychle mizet, což ho zbaví jeho bonusu interaktivity.
Čas přiškrcení poskytuje chvilky oddechu [grace periods], které procesům dovolí krátké využití CPU, aniž by byly penalizovány. Množství času na oddech může být upraveno pomocí dvou nastavovátek exportovaných kódem přiškrcení. "Oddech 1" je množství času, které nové procesy dostanou, aby mohly být nastaveny jejich hodnoty průměrů předtím než budou předhozeny škrtícímu mechanismu. "Oddech 2" je doba, po kterou mohou procesy přesáhnout předpokládaný procesorový čas, než začne fungovat přiškrcování. Ohledně přidání těchto nastavovátek se objevilo několik stížností; vypadají jako další obskurní způsob ladění jádra, který stejně většina administrátorů nebude umět správně využít. Takže se tlačilo na to, aby byla nastavovátka nahrazena obyčejným přepínačem zapnuto/vypnuto. Systémy určené pro interaktivní využití ponechají přiškrcování zapnuté, serverové systémy ho prostě celé vypnou. Vyřešení této záležitosti možná zpozdí přijetí patche, i když proti jeho zbytku nikdo nic nenamítá.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Mě se ty zprzněné překlady moc líběj (pokud je uveden v závorce originál).
Takže jsem v podstatě chtěl říct (teď už stručně bez pseudointelektuálních kydů 
): "Pokud použiju 'poradní panel' místo 'poradní skupina', nemůžu se divit, že si leckdo představí tunu betonu a pak nad tím nahlas kroutí hlavou. To, že slovo 'panel' v jistých obskurních koutech češtiny opravdu může znamenat 'skupina' na tom nic nemění." To slovo je v tomhle významu imho prostě divné.
P.S.: Díky za Jaderné noviny, moc se mi po nich stýskalo. Pokud kritice zbývají už jenom hovadiny typu poradní panel, je to myslím dobrý indikátor kvality
zrovna ta "funkcionalita" neni zrovna manažerský výrazAle to také nepoužívám
mluví ze mě chlastV tuhle hodinu? Závidím...
Pokud kritice zbývají už jenom hovadiny typu poradní panel, je to myslím dobrý indikátor kvalityTo mě těší. Víc se bojím technických termínů.
hlavní vylepšení, které se mi líbilo, byl stručný a přehledný souhrn plánovaných změn v 2.6.17.No, ona je to spíš náhoda, protože i tentokrát jsem čerpal pouze z LWN.net. Další zdroj kratších zpráv stále sháním.
koukam anglicky kerneltraffic.org uz byl docasne/trvale pozastaven.Už je to dost dlouho. Ostatně jsem o tom mluvil v blogu - bylo potřeba najít náhradu.
jiny zdroj by mohl byt treba i kerneltrap.org ?Už jsem Jeremymu psal, protože to kdosi navrhl v diskuzi pod minulým dílem. Čekám, co na to řekne.
4.4.2006 11:21
Jan Zahornadsky | skóre: 22
| blog: hans_blog
4.4.2006 12:44
DjAARA | skóre: 32
| Praha|Náklo|Olomouc
. Tedy ze ne vsichni maji stejny nazor a ze stejne spolecne pracuji na vylepsovani.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
