Jaderné noviny - 2. 7. 2008

14. 8. 2008 | Jirka Bourek | Jaderné noviny | 3356×

Aktuální verze jádra: 2.6.26-rc8. Citáty týdne: James Bottomley, Andrew Morton, Theo de Raadt. Programátor Ext4 Ted Ts'o konvertoval svůj laptop. Aby politika napájení prostě fungovala. TASK_KILLABLE. Nějaké statistiky vývoje 2.6.26 - a dalších.

Obsah

• Aktuální verze jádra: 2.6.26-rc8
• Citáty týdne: James Bottomley, Andrew Morton, Theo de Raadt
• Programátor Ext4 Ted Ts'o konvertoval svůj laptop
• Aby politika napájení prostě fungovala
• TASK_KILLABLE
• Nějaké statistiky vývoje 2.6.26 - a dalších
  • Co dál?

Aktuální verze jádra: 2.6.26-rc8

Současné vývojové jádro 2.6 zůstává 2.6.26-rc8; během minulého týdne nebyly vydány žádné předverze.

Současné stabilní jádro 2.6 zůstává 2.6.25.9. Aktualizace 2.6.25.10 s asi tuctem oprav je v současnosti v procesu revidování; pravděpodobně bude vydáno 3. července.

Citáty týdne: James Bottomley, Andrew Morton, Theo de Raadt

Open source je rychlý, když jde o pokrok ke společným cílům... to když cíle nejsou společné, pokrok uvázne.

-- James Bottomley

Když dáme věci do sysfs, pak je lidi POUŽIJÍ a my je BUDEME MUSET podporovat navždy. Ukázat na nějaký dokument a říct "kontaktujte mého právníka" to prostě nezkrátí. sysfs je část jaderného ABI, měli bychom tam svá rozhraní navrhovat stejně opatrně, jako navrhujeme každá jiná.

-- Andrew Morton

Doufám, že nic, co kdy řeknu, nebude odrazovat naše vývojáře nebo komunitu od toho, co je správné. Neuvědomil jsem si, že programátoři GNU a Linuxu jsou tak poslušní otroci.

-- Theo de Raadt

Programátor Ext4 Ted Ts'o konvertoval svůj laptop

Velký krok ve vývoji nového souborového systému je, když jsou si jím vývojáři dost jisti na to, aby mu svěřili svá data. Zdá se, že tohoto bodu bylo u ext4 dosaženo, protože Ted Ts'o ho začal používat na svém laptopu. Zatím jsem díky používání ext4 při práci narazil na jednu chybu (pokud je povolená zpožděná alokace, i_blocks se neaktualizuje, dokud nedojde k alokaci bloku, takže těsně po vytvoření mohou soubory vypadat, že mají 0k velikost bloku, což je matoucí/nešťastné), ale zatím nic super vážného. Nicméně budu zálohovat poněkud častěji, dokud si nebudu zcela jistý, že jsou věci pevné jako skála!

Aby politika napájení prostě fungovala

Parametr sched_mc_power_savings (chytře skrytý pod /sys/devices/system/cpu) byl zaveden v jádře 2.6.18. Jestliže je tento parametr nastaven na jedničku (výchozí je nula), zajímavým způsobem změní kód plánovače, který se stará o vyvažování zátěže: plánovač se bude snažit, aby procesy shromáždil na co nejmenším počtu CPU. Jestliže systém nebude pod velkou zátěží, tato politika vyústí ve stav, kdy budou některé procesory zcela bez práce; ty potom bude možné hluboce uspat a nechat v tomto stavu nějaký čas. To samozřejmě vyústí v menší spotřebu energie, což je dobrá věc.

Vaidyanathan Srinivasan si nedávno všiml, že i když tato politika v mnoha situacích funguje dobře, jsou jiné, ve kterých by věci mohly být lepší. Politika sched_mc_power_savings je relativně konzervativní v tom, jak nakládá procesy jednotlivým CPU; snaží se tato CPU nepřetížit a nezpůsobit tak vznik příliš velkých latencí u aplikací. Výsledkem je, že pracovní zátěž se na velkém systému může rozšířit na více CPU, než by bylo optimální, obzvláště pokud přichází v dávkách. Vaidyanathan tedy navrhuje, aby byla politika šetření energií flexibilnější, aby byl správce systému schopen vybrat kombinaci úspory energie a latence, která by pro danou zátěž dobře fungovala. Na systémech, kde hodně záleží na úspoře energie, by mohl být vybrán agresivnější režim (který by procesy shromáždil na CPU těsněji).

Tento návrh byl kontroverzní. Nikdo nepochybuje o tom, že mít chytřejší politiku úspory energie je dobrý nápad. Ale objevil se odpor k vytváření dalších ladících knoflíků k ovládání této politiky; místo toho mají lidé pocit, že jádro by mělo optimální politiku určit samo. Jak říká Andi Kleen:

Potřeba nastavování v podstatě znamená "vzdáváme to, pojďme problém přehodit na uživatele", což není hezké. Mám podezření, že mnoho uživatelů ani nebude vědět, jestli jejich zátěž přichází v dávkách, nebo ne. Nebo mohou mít oba druhy zátěže - dávkovou i nedávkovou - zároveň.

Na tuto námitku se objevilo několik odpovědí. Jedna je, že systém nemůže sám o sobě vědět, jaké priority uživatelé/správci mají. Tyto priority se dokonce mohou měnit s časem, když se během špiček zdůrazní výkonnost a jindy snížení spotřeby. Navíc ne všichni uživatelé vidí "výkonnost" stejným způsobem; někteří chtějí rychlé odezvy, zatímco jiní kladou větší důraz na vysokou propustnost. Jestliže systém nemůže simultánně optimalizovat podle všech těchto parametrů, bude k tomu, aby vybral nejlepší politiku, potřebovat vedení odněkud z venku.

A zde přichází další odpověď: toto vedení by mohlo přicházet z uživatelského prostoru. Jednoúčelový program běžící na velkých systémech by mohl monitorovat výkonnost důležitých aplikací a nastavovat zdroje (a politiky) tak, aby bylo dosaženo požadovaných výsledků. Nebo - v trochu odlišném pohledu - jednotlivé programy by mohly registrovat své požadavky na výkonnost a očekávané chování. V takovém případě by jádro bylo pověřeno nějakým způsobem vzít různá očekávání jednotlivých aplikací a vytvořit rozumnou sadu politik.

Uprostřed toho všeho bylo poukázáno na to, že mechanismus, kterým lze jádru sdělit svá očekávání, již existuje: úroveň nice (priorita) spojená s každým procesem. V jednoduchém pohledu na svět by nice úroveň procesu mohla říct jádru, jak se zařídit s ohledem na šetření energií; na systému s mnoha procesy se zvýšeným nice by se tyto procesy mohly shromáždit na podmnožinu procesorů během období relativně nízké aktivity. Zjednodušeně by tato politika říkala, že nemá cenu zapínat víc procesorů jenom kvůli tomu, aby procesy o nízké prioritě měly vyšší propustnost.

Netrvalo ale dlouho, než bylo poukázáno na situace, kdy by použití úrovně nice vedlo ke špatným výsledkům. Peter Zijlstra pozoroval, že má procesy se zvýšeným nice (vytvořené distcc), které by měly mít přístup k veškerému výpočetnímu výkonu CPU, ale neměly by soupeřit s interaktivními procesy na stejném systému. V takovém případě by tyto procesy měly mít vysokou hodnotu nice, co se týče využívání CPU, ale to by nemělo interferovat s jejich schopností přesunout se na jiné volné CPU, pokud takové je. Takže výsledná odpověď může mít formu odděleného příkazu "powernice", který by reguloval prioritu procesu, pokud jde o zvýšení spotřeby systému.

Úrovně nice mohou (i nemusí) být dostatečnou informací, podle které by systém mohl vybrat optimální politiku napájení. Uplyne ale nějaký čas, než to někdo skutečně bude vědět; práce na optimalizaci spotřeby energie - obzvláště u serverových systémů - není moc daleko. Takže tlak na přidání ladících knoflíků pro politiku spotřeby může pokračovat z jednoduchého důvodu: lidé chtějí způsob, jak experimentovat s různými politikami a zjistit, jaké jsou výsledky. Dokud nebudeme skutečně vědět, jaké jsou efekty různých politik - jak co se týče spotřeby, tak výkonnosti systému - bude těžké vytvořit systém, který by mohl vhodnou politiku samostatně zvolit.

TASK_KILLABLE

Jako většina verzí unixu má Linux dva základní způsoby, jak uspat proces. Proces, který je přiveden do stavu TASK_INTERRUPTIBLE bude spát, dokud ho buď (1) něco neprobudí, nebo (2) nepřijme nemaskovaný signál. Stav TASK_UNINTERRUPTIBLE na druhou stranu signály ignoruje; procesy v tomto stavu potřebují explicitní probuzení předtím, než mohou dále běžet.

Oba typy uspání mají své výhody a nevýhody. Přerušitelný spánek umožňuje rychlejší reakce na signály, ale programování je složitější. Jaderný kód, který používá přerušitelný spánek, musí vždy kontrolovat, jestli byl probuzen v reakci na signál, a pokud to tak je, uklidit všechno, co dělal, a vrátit do uživatelského prostoru -EINTR. Protistrana v uživatelském prostoru také musí rozpoznat, že bylo systémové volání přerušeno, a odpovídajícím způsobem reagovat; ne všichni programátoři v uživatelském prostoru jsou v této oblasti známí svoji pečlivostí. Tím, že je spánek nepřerušitelný, lze tyto problémy vyřešit za cenu, že je spánek, ehm, nepřerušitelný. Pokud se neobjeví očekávaná událost, která má proces probudit, bude proces čekat navždy a obvykle s tím nelze udělat nic jiného, než rebootovat systém. To je zdroj nenáviděných nezabitelných procesů, které ps ukazuje ve stavu "D".

Vzhledem k vysoce nepřípustné povaze nesmrtelného procesu by si jeden mohl myslet, že přerušitelný spánek by se měl použít, kdykoliv je to možné. Problém s touto myšlenkou je v tom, že v mnoha případech by zavedení přerušitelného spánku pravděpodobně vedlo k chybám v aplikacích. Jak nedávno poznamenal Alan Cox:

Unixová tradice (a tím téměř všechny aplikace) věří, že všechny zápisy do souboru jsou nepřerušitelné signálem. Nebylo by bezpečné ani praktické tuto garanci měnit.

Takže by se zdálo, že nám nezbývá, než se navždy smířit s občasným zablokovaným a nesmrtelným procesem.

Nebo možná ne. Před nějakou dobou si Matthew Wilcox uvědomil, že mnoho z obav z chyb v aplikacích se nevztahuje na případy, kdy bude aplikace stejně zabita. Nezáleží na tom, jestli vývojář myslel na možnost, že systémové volání bude přerušeno, když je dané systémové volání stejně odsouzeno k tomu, že se nikdy do uživatelského prostoru nevrátí. Proto Matthew vytvořil nový stav uspání, který nazval TASK_KILLABLE; chová se jako TASK_UNINTERRUPTIBLE s tou výjimkou, že smrtící [fatal] signály spánek přeruší.

S TASK_KILLABLE přichází nová sada primitiv pro čekání na události a získávání zámků:

int wait_event_killable(wait_queue_t queue, condition);
long schedule_timeout_killable(signed long timeout);
int mutex_lock_killable(struct mutex *lock);
int wait_for_completion_killable(struct completion *comp);
int down_killable(struct semaphore *sem);

U každé z těchto funkcí je návratová hodnota nula pro normální, úspěšný návrat, nebo negativní chybový kód v případě smrtícího signálu. V tom druhém případě by jaderný kód měl provést pročištění a vrátit se, čímž by umožnil zabití procesu.

Patch TASK_KILLABLE byl začleněn do jádra 2.6.25, což ale neznamená, že problém s nesmrtelnými procesy zmizel. Počet míst v jádře (mluvíme o verzi 2.6.26-rc8), která tento nový stav skutečně využívají, je vcelku malý - tak malý, že se jeden nemusí bát o to, že mu při pokusu je spočítat dojdou prsty. Kód NFS klienta byl konvertován, což může být pouze vítáno. Dalších využití TASK_KILLABLE je ale málo a žádné z nich není v ovladačích zařízení, což jsou místa, kde se procesy zasekávají často.

Může trvat nějaký čas, než nové API najde v jádře široké využití, obzvláště když doplňuje existující funkci, která po většinu času funguje dostatečně dobře. Navíc výhody masové konverze existujícího kódu tak, aby používal smrtelný spánek, nejsou zcela zjevné. Jsou ale téměř jistě místa, která by se v jádře touto změnou dala vylepšit, pokud by uživatelé a vývojáři identifikovali body, kde se procesy zaseknou. Také dává smysl použít smrtelný spánek v novém kódu, pokud nebude nějaký významný důvod nepovolit přerušení vůbec.

Nějaké statistiky vývoje 2.6.26 - a dalších

Když bylo vydáno 2.6.26-rc1, Jonathan Corbet si všiml, že s pouhými 7500 commity to vypadá, že 2.6.26 bude menší, než je na vývojový cyklus obvyklé. Nicméně je zajímavé, že to 2.6.26 dohnalo. V době psaní tohoto článku (tj. čeká se na 2.6.26-rc9) tento vývojový cyklus začlenil 10 102 sad změn s čistým přírůstkem 169 439 řádek kódu. Stále je menší než 2.6.25, ale rozhodně není malý. Základna vývojářů zůstává stejně široká jako vždy: do 2.6.26 přispělo 1065 vývojářů (reprezentujících okolo 150 společností); o něco více než třetina z nich jen jednou sadou změn.

Vývojový model 2.6 říká, že jádro změn by mělo být začleněno během začleňovacího okna (před vydáním -rc1), poté by měly přijít jenom opravy. Zde je tabulka, jak to vypadalo v nedávných vydáních:

Verze	Začleněných sad změn
	Do -rc1	Po -rc1
2.6.23	4505	2570
2.6.24	7132	3221
2.6.25	9629	3078
2.6.26	7555	2577

Takže zatímco většina velkých patchů se do jádra dostane během začleňovacího okna, nejméně 25&nbs,; % celku - a často více - přichází později. To je hodně oprav.

Kdo byli tentokrát nejaktivnější vývojáři? Tady je prvních 20:

Nejaktivnější vývojáři 2.6.26

Podle sad změn Harvey Harrison 218 2,2 % Bartlomiej Zolnierkiewicz 197 1,9 % Glauber Costa 195 1,9 % Adrian Bunk 180 1,8 % Joe Perches 160 1,6 % Pavel Emelyanov 148 1,5 % Ingo Molnár 144 1,4 % Denis V. Lunev 140 1,4 % Michael Krufky 130 1,3 % Mauro Carvalho Chehab 116 1,1 % Al Viro 114 1,1 % David S. Miller 103 1,0 % Tejun Heo 96 0,9 % Johannes Berg 96 0,9 % Alan Cox 91 0,9 % Takashi Iwai 88 0,9 % YOSHIFUJI Hideaki 85 0,8 % Alexey Starikovskiy 84 0,8 % Ivo van Doorn 80 0,8 % Bjorn Helgaas 77 0,8 %

Podle změněných řádek Stephen Hemminger 41762 5,9 % Adrian Bunk 28523 4,0 % David S. Miller 19178 2,7 % Steven Toth 18681 2,6 % Ben Hutchings 15535 2,2 % Frank Blaschka 14527 2,0 % Xiantao Zhang 12935 1,8 % Hans Verkuil 12393 1,7 % Tejun Heo 10462 1,5 % Sebastian Siewior 9519 1,3 % Harvey Harrison 9161 1,3 % Peter Tiedemann 8483 1,2 % Matthew Wilcox 8059 1,1 % Paul Walmsley 7635 1,1 % Kumar Gala 7152 1,0 % Andrew Victor 7062 1,0 % Johannes Berg 6544 0,9 % Glauber Costa 6260 0,9 % Mike Frysinger 6177 0,9 % Joe Perches 5773 0,8 %

Co se počtu sad změn týče, Harvey Harrison se na vrchol seznamu dostal velmi různorodými údržbářskými opravami. Bartlomiej Zolnierkiewicz pokračuje ve významné snaze o pročištění IDE subsystému, i když většina distributorů tento kód již nepoužívá a přesunuli se místo toho k nové PATA vrstvě. Glauber Costa neúnavně pracuje na kódu architektury x86; konkrétně dál pracuje na cíli v co největším možném rozsahu sjednotit 32bitový a 64bitový kód. Adrian Bunk udělal kariéru na čištění základny kódu a eliminaci kódu, který není potřeba. A Joe Perches věnoval hodně času eliminaci varování ze skriptu checkpatch.pl.

Od vývojářů se objevily stížnosti, že množství "pročišťovacích" patchů se dostává do bodu, kde se srovnává s ostatními a narušuje "skutečnou práci". Část tohoto množství vidíme zde, tři z pěti největších přispěvatelů sad změn dělají pročišťovací práci, z čehož některá je považována za cennější než jiná.

Co se týče počtu změněných řádek, většinou vidíme jinou sadu vývojářů. V tomto případě si první místa vysloužilo mazání kódu. Stephen Hemminger konečně uspěl se zbavením se starého ovladače sk98lin. Adrian Bunk vytrhl ovladač bcm43xx, softwarovou MAC vrstvu ieee80311, ovladač xircom_tulip_cb a různé další kusy a kousky. David Miller odstranil hodně starého SPARC kódu, ale nahradil jej různými jinými schopnostmi; také vzal nízkoúrovňový správce paměti PowerPC a zobecnil ho. Steven Toth pracuje s vrstvou Video4Linux; přidal několik nových ovladačů a nějaká pročištění. Ben Hutchings přidal ovladač Solarstorm SFC4000.

Když se zamyslíme na vlastnostmi 2.6.26, záležitosti, které přijdou na mysl, jsou KGDB, téměř hotové síťové jmenné prostory, téměř hotová podpora mesh síťování, fungující (měli bychom říct "téměř hotový"?) skupinový plánovač reálného času [realtime group scheduler], vázaná připojení pouze pro čtení, podpora pro tabulku atributů stránek [page attribute table], infrastruktura ladění objektů a samozřejmě velká hromada nových ovladačů. Jeden se musí do seznamů nahoře dívat dlouho, aby našel vývojáře, kteří tuto práci odvedli (někteří tam určitě jsou). To jenom posiluje důležitou námitku: je zájem na tom počítat sady změn a změněné řádky, ale korelace mezi těmito čísly a důležitými úspěchy v programování jádra je při nejlepším slabá. Bohužel "skutečná práce" se jakýmkoliv automatizovatelným způsobem strašně těžce měří.

Ale co; vrátíme se k číslům, která měřit můžeme. Zde jsou nejaktivnější firmy, které se podílely na 2.6.26:

Nejaktivnější zaměstnavatelé v 2.6.26

Podle sad změn (Žádná) 2085 20,6 % Red Hat 1130 11,2 % (Neznámá) 906 8,9 % IBM 609 6,0 % Novell 597 5,9 % Intel 469 4,6 % Parallels 312 3,1 % SGI 211 2,1 % Movial 180 1,8 % Oracle 142 1,4 % Analog Devices 134 1,3 % HP 124 1,2 % MontaVista 122 1,2 % (Konzultant) 116 1,1 % Freescale 109 1,1 % QLogic 97 1,0 % Fujitsu 95 0,9 % Google 94 0,9 % (Školství) 89 0,9 % Marvell 88 0,9 %

Podle změněných řádek (Žádná) 111703 15,7 % IBM 73601 10,3 % Red Hat 56331 7,9 % Intel 50297 7,1 % (Neznámá) 44699 6,3 % Vyatta 41835 5,9 % Novell 33745 4,7 % Movial 28632 4,0 % Hauppauge 20234 2,8 % Analog Devices 18363 2,6 % (Konzultant) 16397 2,3 % Solarflare 15585 2,2 % Freescale 15090 2,1 % MontaVista 14013 2,0 % QLogic 13327 1,9 % SGI 10351 1,5 % Marvell 7881 1,1 % Wind River 7770 1,1 % Oracle 7680 1,1 % Pengutronix 7334 1,0 %

Tento seznam se mezi vydáními příliš nemění; konkrétně firmy na vrcholu jsou vždycky stejné.

Pokud se podíváme na to, kdo přidává značky "Kým podepsáno" [Signed-off by] ke kódu, který nenapsal, získáme přehled o tom, kdo dělá vrátné jádra. Zde jsou vývojáři a společnosti, které vedou kód do hlavní řady.

Podpisy v jádře 2.6.26

Podle vývojáře Andrew Morton 1377 14,1 % Ingo Molnár 961 9,8 % David S. Miller 667 6,8 % John W. Linville 551 5,6 % Mauro Carvalho Chehab 543 5,6 % Jeff Garzik 471 4,8 % Thomas Gleixner 279 2,9 % Greg KH 267 2,7 % Linus Torvalds 256 2,6 % Paul Mackerras 220 2,2 % Takashi Iwai 208 2,1 % James Bottomley 203 2,1 % Len Brown 200 2,0 % Russell King 167 1,7 % Avi Kivity 160 1,6 % Bryan Wu 140 1,4 % Roland Dreier 130 1,3 % Lachlan McIlroy 108 1,1 % Bartlomiej Zolnierkiewicz 94 1,0 % Ralf Baechle 93 1,0 %

Podle zaměstnavatele Red Hat 3010 30,8 % Google 1378 14,1 % (Žádná) 1000 10,2 % Novell 731 7,5 % IBM 577 5,9 % Intel 497 5,1 % linutronix 283 2,9 % Linux Foundation 256 2,6 % (Neznámá) 206 2,1 % (Konzultant) 206 2,1 % Hansen Partnership 203 2,1 % SGI 166 1,7 % Qumranet 160 1,6 % Analog Devices 149 1,5 % Cisco 130 1,3 % MIPS Technologies 93 1,0 % Oracle 57 0,6 % Freescale 55 0,6 % Renesas Technology 54 0,6 % Univ. of Michigan CITI 47 0,5 %

Ani zde se čísla mezi vývojovými cykly příliš neliší. Správci subsystémů se nemění často.

Co dál?

Tento vývojový cyklus je první, ve kterém byl v činnosti strom linux-next. V tomto stádiu cyklu by linux-next měl vypadat velmi podobně jako 2.6.27 - nebo alespoň 2.6.27-rc1. Autor článku stáhl 2. července strom linux-next a udělal nějaké statistiky; strom obsahuje 6527 sad změn od 619 vývojářů. Dotýká se těsně přes 400 000 řádek kódu a přidává 38 000 řádek.

Pokud můžeme linux-next věřit, nejaktivnější vývojáři 2.6.27 budou:

Nejaktivnější vývojáři před 2.6.27

Podle sad změn Avi Kivity 499 7,6 % Artem Bityutskiy 292 4,5 % Bartlomiej Zolnierkiewicz 150 2,3 % Ingo Molnár 142 2,2 % Yinghai Lu 139 2,1 % Adrian Hunter 121 1,9 % Alan Cox 101 1,5 % Xiantao Zhang 100 1,5 % Tomas Winkler 91 1,4 % Rusty Russell 89 1,4 % David Woodhouse 86 1,3 % Adrian Bunk 84 1,3 % Steven Rostedt 83 1,3 % Jonathan Corbet 74 1,1 % Arnd Bergmann 73 1,1 % Jean Delvare 67 1,0 % Harvey Harrison 64 1,0 % David Chinner 63 1,0 % Lennert Buytenhek 61 0,9 % Thomas Gleixner 61 0,9 %

Podle změněných řádek David Woodhouse 44833 6,7 % Artem Bityutskiy 41891 6,3 % Eilon Greenstein 18614 2,8 % Xiantao Zhang 17223 2,6 % Alan Cox 14850 2,2 % Jaswinder Singh 10805 1,6 % David Brownell 9618 1,4 % Stephen Rothwell 9043 1,4 % Lennert Buytenhek 9029 1,3 % Avi Kivity 8593 1,3 % Steven Rostedt 7923 1,2 % Adrian Bunk 7424 1,1 % Laurent Pinchart 7200 1,1 % Yinghai Lu 6850 1,0 % Yaniv Rosner 6512 1,0 % Carsten Otte 6442 1,0 % Tomas Winkler 6250 0,9 % Josh Boyer 5292 0,8 % Adrian Hunter 5155 0,8 % Michael Chan 5133 0,8 %

Tato čísla odrážejí mnoho z větších změn, které lze v 2.6.27 očekávat: neuvěřitelné množství práce na KVM, začlenění souborového systému UBIFS, sledovací framework ftrace, značné přepracování TTY vrstvy, spousta vyhozeného firmwaru a pokračující práci na odstranění velkého jaderného zámku.

Bude nanejvýš zajímavé porovnat tato čísla s tím, co se skutečně objeví v 2.6.27-rc1. Nedávná čísla naznačují, že pár patchů se dostane do hlavní řady bez pobytu ve stromě linux-next - buď to, nebo 2.6.27 bude relativně malé vydání. Když nic jiného, uvidíme, kteří vývojáři ještě nedostali svou práci do linux-next kvůli testování integrace před začleňovacím oknem.

       

Komentáře

[Semo]

Tej cervenej je nejak privela.

[frEon]

jj, neni uzavrenej <span> v odstavci Programátor Ext4 Ted Ts'o konvertoval svůj laptop

[trekker.dk]

Už zase? Já to budu muset kontrolovat v něčem jiném, protože Iceape ten <span> uzavírá automaticky.

[Robert Krátký]

protože Iceape ten <span> uzavírá automaticky.

Totéž dělá Konqueror... opraveno.

[e.lisak]

pravdepodobne preklep:
&nbs,; -> '& nbsp ;'

[cronin]

Len mi tak napadlo, ked som si precital, ze rc1 meni 400 tisic riadkov: kolko riadkov ma aktualne jadro?

[JohnnyDoe]

kolko riadkov ma aktualne jadro?

ondra@ompc /usr/src/linux-2.6.23-tuxonice-r10 $ cat $(find . -name "*.c") | wc --lines
6125537

Sice neni uplne aktualni, ale pro predstavu by to mohlo stacit :).

[Peter Fodrek]

ale to je statistika konciaca na 2.6.24 a je asi pol roka stara

statistka linux foundation 4.2008

[stybla]

Aktualizace 2.6.25.10 s asi tuctem oprav je v současnosti v procesu revidování; pravděpodobně bude vydáno 3. července.

Tohle jsem moc nepochopil. Nema tam byt 3. zari?

[alium]

ne, aktualní jádro řady 2.6.25 je 2.6.25.15, takže 10. vyšla skutečně v červenci. Jaderné noviny se totiž překládají se zpožděním několika týdnů.
P.S. Aktualní jádro přece není 2.6.26-rc8

[stybla]

A sakra, asi jsem jeste spal :)

[Cubic]

Nejdriv co me prekvapilo:

v zebricku firem s nejvice zmenenymi radky Hauppauge - vyrobce televiznich karet, necekane, potesujici

Co me pobavilo:

cele to stoji za precteni ale vyberu par perel na ukazku:
Theo de Raadt:

...Personally I believe that all the other free operating systems added together have worked MUCH LESS on this than we have...

-----

...you are trying to say happy Linux things but there are no facts to support that the Linux crew or FSF has done ANYTHING which has gotten documentation for hardware out there. They have failed to use their dominant position to anyone else, and they have done a damn poor job of even supporting themselves...

-----

...Collectively the Linux developers have done DICK to pressure vendor documentation releases...

a posledni

...The Linux developers are selfish dickheads who have exactly the same monopolistic mindset as Microsoft -- who also signs NDAs with vendors. I see nothing different about their processes...

[R]

Ten clovek nie je vporiadku...

[mikro]

Skor nez vynasas sudy nad mentalnou sposobilostou jedneho z hlavnych OpenBSD vyvojarov, skus si precitat ten clanok/mail -- uvedene citaty su vytrhnute z kontextu, v originale (celku) jeho myslienky maju celkom rozumnu pointu.

P.S. Nie, nie som nejaky anti-Linux, BSD-love fanatik, paradoxne si obvykle o tom chlapikovi tiez myslim svoje, ale tentoraz mu fakt davam zapravdu.

[Cubic]

Me bylo jasne, ze budou vytrhnute z kontextu. Udelal jsem to spis jako bulvarni upoutavku na cely odkazovany email, ktery je vhodne si precist cely. Jinak se naprosto ztotoznuji s tvym post scriptum.

[stybla]

Mam z toho(=e-mailu) vice nez smisene pocity.

[deda.jabko]

to s tim planovanim uloh je docela dobra featura. o tom jsem nevedel... docela to zveda vykon, obzvlast, na intelacke architekture s vice procesory

[Marex]

Navíc výhody masové konverze existujícího kódu tak, aby používal smrtelný spánek, nejsou zcela zjevné.

Tahle veta me opravdu pobavila ... a myslim, ze i ostatni milovnici Bckovych hororu ji oceni

[nebo vaše jméno]

Neda sa zabit neprerusitelny spanok pomocou kill -9?

[Hynek (Pichi) Vychodil]

Ne.

[TomCat1]

Ano.

[moole]

Ne.

[Jiří Svoboda]

Ano.

(Ano, nedá.)

[geebranz]

That is okay

cryotherapyspokanewa.com