Jaderné noviny - 31. 10. 2007

28. 11. 2007 | Robert Krátký | Jaderné noviny | 3879×

Aktuální verze jádra: 2.6.24-rc1. Citáty týdne: Casey Schaufler, Andrew Morton, Linus Torvalds. API pro řetězení scatterlistů. Linuxové kvalifikace: oprava CAP_SETPCAP. Poznámky z kontejneru: kontrolní skupiny, jmenné prostory pro PID, síťové jmenné prostory, hijack().

Obsah

• Aktuální verze jádra: 2.6.24-rc1
• Citáty týdne: Casey Schaufler, Andrew Morton, Linus Torvalds
• API pro řetězení scatterlistů
• Linuxové kvalifikace: oprava CAP_SETPCAP
• Poznámky z kontejneru
  • Kontrolní skupiny
  • Jmenné prostory pro PID
  • Síťové jmenné prostory
  • hijack()

Aktuální verze jádra: 2.6.24-rc1

Aktuální předverze je (k 31. 10. 2007) i nadále 2.6.24-rc1. Do hlavního repozitáře proudí opravy (včetně japonského překladu dokumentu SubmittingPatches), ale -rc2 zatím ještě nevyšla.

Starší jádra: chystá se stabilní aktualizace 2.6.22.11; vyjít by měla kolem 2. listopadu. Obsahuje 26 patchů řešících několik problémů. Půjde pravděpodobně o poslední aktualizaci 2.6.22.

2.6.16.56-rc2 vyšlo 29. října; přidává hrstku oprav.

Citáty týdne: Casey Schaufler, Andrew Morton, Linus Torvalds

Víte proč Unix uspěl a MULTICS ne? To proto, že Unix měl mode bity [režimové bity] a MULTICS měl ACL. Naštěstí pro ty z nás, kteří jsou hrdí na tituly jako "Bezpečnostní expert" nebo "Trust technologist", existuje dost vysoko postavených paranoiků, aby nika Důvěryhodných systémů úplně nezanikla, takže si můžeme žít jako rockové hvězdy. Dobrá zpráva je, že situace není o nic horší než v případě lidí, díky kterým máte Infiniband nebo Itanium.

-- Casey Schaufler

Prosím vás, vždycky patche připravujte a testujte oproti nejnovějšímu jádru. 2.6.23 opravdu _není_ nejnovější jádro. Mezi 2.6.23 a 2.6.24-rc1 je 50MB diff. To je velký rozdíl.

-- Andrew Morton

Pravidlo č. 1 při programování jádra: *nikdy* si nemyslete, že věci skutečně fungují tak, jak se to píše v dokumentaci.

-- Linus Torvalds

API pro řetězení scatterlistů

Na otázku, která ze změn v 2.6.24 by nejspíše způsobila problémy, by informovaný pozorovatel asi odpověděl, že sloučení i386 a x86_64. Nakonec však tahle velká sada patchů prošla do jádra jen s relativně málo problémy, ale jedna o dost menší změna měla nepříjemný dopad. Jedná se o aktualizované API pro správu scatterlistů, které se používají při scatter/gather I/O. Přestalo kvůli ní fungovat několik ovladačů v rámci jádra, takže se zdá pravděpodobné, že ovlivní i hodně kódu, který není součásti jádra.

Scatter/gather I/O systému umožňuje provádět DMA I/O operace na bufferech, které jsou roztroušené po fyzické paměti. Představte si například velký (vícestránkový) buffer vytvořený v uživatelském prostoru. Aplikace vidí souvislý rozsah virtuálních adres, ale fyzické stránky téměř určitě nebudou vedle sebe. Pokud má být tento buffer zapsán na zařízení v rámci jediné I/O operace, musí se stát jedna ze dvou věcí: 1) zkopírovat data do fyzicky souvislého bufferu nebo 2) zařízení musí být schopné pracovat se seznamem fyzických adres a délek a z každého segmentu vzít správný objem dat. Scatter/gather I/O může velmi zvýšit účinnost I/O operací, protože odstraňuje nutnost kopírovat data do souvislých bufferů. Zároveň se tím řeší to, že vytváření velkých, fyzicky souvislých bufferů by samo o sobě mohlo být problematické.

V jádře je buffer, který bude použit ve scatter/gather DMA operaci, reprezentován polem jedné nebo více scatterlist struktur. Tato struktura je definována v <linux/scatterlist.h>. Pole bylo tradičně omezeno tak, aby se vešlo na jedinou stránku, což stanovovalo maximální délku scatter/gather operací. Tento limit však zpomaloval práci na high-endových systémech, které by jinak mohly těžit z přenosu opravdu velkých bufferů (obyčejně na a z diskových zařízení). Proto se hledal způsob, jak limit obejít; jednou možností jsou patche implementující velké velikosti bloků, které se v konferencích občas vynoří. Ale řešení, které se dostalo do jádra 2.6.24, je odstranit limit délky scatter/gather seznamů tím, že se jim umožní řetězení.

Zřetězený scatter/gather seznam může být složen z více než jedné strany a tyto strany budou pravděpodobně roztroušeny po fyzické paměti. Když je řetězení dokončeno, použije se dvojice nízkořádových bitů v ukazateli bufferu k označení položek řetězu na konci seznamu. Přítomnost speciálních bitů a ukazatelů řetězů vynucuje určité změny ve způsobu práce ovladačů se scatterlisty.

Ovladače, které neprovádějí řetězení, budou svá scatterlist pole alokovat jako obyčejně - většinou prostřednictvím volání kcalloc() nebo podobně. Před 2.6.23 nebyla potřeba žádná inicializace (kromě případného vynulování celého pole). To se však změnilo; ovladače by teď měly inicializovat scatterlist pole pomocí:

    void sg_init_table(struct scatterlist *sg, unsigned int nents);

sg ukazuje na alokované pole a nents je počet alokovaných scatter/gather položek.

Stejně jako dříve by měl ovladač projít segmenty bufferu a nastavit pro každý segment jeden scatterlist záznam. Není však možné přímo zadat ukazatel page: v 2.6.24 už ten ukazatel neexistuje. Záznam scatterlistu se bude nastavovat pomocí jednoho z těchto dvou způsobů:

    void sg_set_page(struct scatterlist *sg, struct page *page,
		     unsigned int len, unsigned int offset);

    void sg_set_buf(struct scatterlist *sg, const void *buf,
	      	    unsigned int buflen);

Scatterlisty v 2.6.24 také vyžadují, aby byl konec seznamu označen. To se provede při zavolání sg_init_table(), takže ovladače nebudou muset konec označovat explicitně. Pokud daná I/O operace nevyužije všechny položky alokované v seznamu, měl by ovladač poslední segment označit:

    void sg_mark_end(struct scatterlist *sg, unsigned int nents);

nents je počet platných položek scatterlistu.

Po namapování scatterlistu (např. funkcí dma_map_sg()) bude muset ovladač výsledné DMA adresy naprogramovat do hardwaru. Starý přístup procházení pole nebude fungovat; místo toho by se měl ovladač posunout na další položku scatterlistu pomocí:

    struct scatterlist *sg_next(struct scatterlist *sg);

Návratová hodnota bude další položka, která má být zpracována - nebo NULL, pokud bylo dosaženo konce seznamu. Připraveno je také makro for_each_sg(), které je možné použít pro iteraci přes celý scatterlist; nejčastěji bude používáno v kódu, který vypadá asi takto:

    int i;
    struct scatterlist *list, *sgentry;

    /* Fill in list and pass it to dma_map_sg().  Then... */
    for_each_sg(i, list, sgentry, nentries) {
	program_hw(device, sg_dma_address(sgentry), sg_dma_len(sgentry));
    }

Ovladače, které chtějí využít řetězení, toho moc dělat nemusejí. Každá část scatterlistu musí být alokována samostatně - pak budou zřetězeny pomocí:

    void sg_chain(struct scatterlist *prv, unsigned int prv_nents,
		  struct scatterlist *next);

Toto volání převede položku scatterlistu prv[nents] na pojítko řetězu k next. Je-li řetězení prováděno, zatímco se naplňuje seznam, prv by nemělo mít uloženo více než prv_nents-1 segmentů. Kromě toho může ovladač zřetězit části seznamu napřed (přičemž alokuje jednu položku pro každý článek řetězu) a pak použít sg_next() k naplnění seznamu, aniž by si musel dělat starosti, kde ty články řetězu jsou.

V tuto chvíli se API pořád ještě vyvíjí v reakci na problémy, které se objevily u ovladačů ve stromu. Nezdá se pravděpodobné, že by před vydáním 2.6.24 došlo k nějakým výrazným změnám.

Linuxové kvalifikace: oprava CAP_SETPCAP

Linuxové kvalifikace už jsou součástí jádra skoro deset let - původně byly začleněny do 2.1, ale v tu dobu je skoro nikdo nepoužíval. Jedna ze základních vlastností, které kvalifikacím chyběly, byla možnost přiřazovat kvalifikace k souborům - ta byla začleněna v 2.6.24. Tím pádem je možné odstranit jeden dlouhodobě používaný hack, který redefinoval správné použití CAP_SETPCAP; i to proběhlo v 2.6.24.

Kvalifikace představují způsob, jak oddělit jednotlivá práva, která jsou obvykle všechna přidělena uživateli root. V souboru linux/capability.h je definovaných 31 kvalifikací, ale existují snahy o rozšíření. Jde o to, že by například program měl mít možnost nastavit systémový čas, aniž by potřeboval všechna práva, která s sebou nese setuid(0) program.

Kvalifikace původně pocházejí z navrhovaného POSIX standardu, který nakonec nebyl přijat, ale mezitím byl začleněn do Linuxu. Od té doby se funkce potácí na okraji zájmu. Má to několik důvodů, z nichž patrně ten nejpodstatnější je, že nebylo možné přiřadit ke spustitelným programům sadu kvalifikačních bitů. Teď, když je možné ukládat kvalifikační bity v rozšířených atributech souborů, může proces dostat správné kvalifikace, když je program spuštěn. Stále však platí standardní unixová práva - uživatelé mohou spouštět pouze programy, ke kterým mají bit x.

Aby bylo vůbec možné kvalifikace používat, byl zapotřebí způsob, jak nastavit kvalifikace běžícího procesu. Pro ten účel byla využita kvalifikace CAP_SETPCAP. Proces s touto kvalifikací, což v praxi znamenalo rootovský proces, mohl nastavovat kvalifikace ostatních procesů. Pokud měl mít jiný proces stejnou možnost - což muselo být pečlivě zváženo - mohl dostat bit CAP_SETPCAP také.

Mohlo to však být používáno jen pro přidávání kvalifikací dlouho běžícím procesům, které nebyly spuštěny rootem (který má kvalifikace všechny), nebo k odebírání kvalifikací od démonů, které běžely s právy roota. Lze si představit i jiná schémata s použitím setuid wrapperů pro utility, které potřebují nějaká oprávnění, ale distribuce nebo nástroje, které by kvalifikace využívaly, nejsou moc rozšířeny.

CAP_SETPCAP nebyl zamýšlen pro tento druh využití, takže nedávný patch mu vrací původní význam. Ačkoliv se to může zdát na první pohled divné, CAP_SETPCAP byl zamýšlen k tomu, aby procesu umožnil změnit své vlastní kvalifikace; dokonce už po aplikování tohoto patche neexistuje žádný způsob, jak by mohl proces změnit kvalifikace jiného běžícího procesu. To je také pravděpodobně největší změna z uživatelského pohledu.

Kvalifikace nejsou jedna sada bitů, nýbrž tři sady, které reprezentují účinné, povolené a dědičné [effective, permitted, and inheritable] kvalifikace procesu. Soubory mají také tři sady kvalifikačních bitů, které jsou navíc zkombinované s těmi, které má proces spouštějící daný soubor. A to na základě "kvalifikačních pravidel" [capability rules] (popsaných v patchi a v článku z minulého roku), aby se určily tři sady pro vytvořený proces.

U procesů obsahuje účinná sada ty kvalifikace, které jsou právě povoleny - těch, u kterých to má dovoleno, se může proces zbavit, jakmile provede odpovídající oprávněnou operaci. Povolená sada je nadřazenou množinou účinné sady, která obsahuje všechny kvalifikace, jež může daný proces mít. Dědičná sada zahrnuje kvalifikace, které se předávají novému programu spuštěnému voláním exec() - a tam přichází na řadu nový CAP_SETPCAP; proces s touto kvalifikací smí měnit svoji dědičnou sadu, aby obsahovala kteroukoliv kvalifikaci, včetně těch, které nejsou v povolené sadě.

Procesům to umožňuje nadělit svým potomkům kvalifikace, které samy nemají, což má některá zajímavá využití. Kromě toho to pomáhá dále oddělovat oprávnění, jelikož není nutné, aby měl proces konkrétní kvalifikace jen kvůli tomu, že je chce předat potomkům. Příklad uvedený u patche to hezky ilustruje: program login moc oprávnění nepotřebuje, ale prostřednictvím jiných mechanismů (například pam_cap) by mohl určitým uživatelům umožnit mít více kvalifikací. Protože proces login sám o sobě tyto další kvalifikace nemá, mohlo by to omezit škody napáchané exploitem loginu.

Není jasné, jestli nedávná vylepšení přinesou kvalifikacím více uživatelů. V tuto chvíli probíhá hodně práce v oblasti bezpečnosti a vypadá to, že kvůli složitosti SELinuxu, která má na svědomí, že ho administráři raději vypínají, než aby se mu snažili porozumět, se komunita ohlíží po jiných řešeních. Je možné, že by kvalifikace mohly být součástí takového řešení, i když také nejsou zrovna triviální. Ačkoliv většina distribucí už si vybrala svůj bezpečnostní model, distro založené na kvalifikacích by bylo zajímavé.

Poznámky z kontejneru

"Kontejnery" jsou druh odlehčené virtualizace, který reprezentují projekty jako OpenVZ. Zatímco virtualizace vytváří nový virtuální stroj, na kterém běží hostovaný systém, implementace kontejnerů fungují tak, že kolem skupin procesu stavějí zdi. Výsledkem je, že virtualizované hostované systémy mají každý spuštěn své jádro (a může jít tedy o jiné operační systémy, než je hostitel), kdežto kontejnerované systémy všechny běží na jádře hostitele. Kontejnery tedy nejsou tolik flexibilní jako plná virtualizace, ale bývají o dost efektivnější.

S jádrem 2.6.23 je v Linuxu virtualizace poměrně dobře podporována. Kontejnery naopak trošku zaostávají. Ukazuje se totiž, že je v mnoha ohledech těžší implementovat kontejnery než virtualizaci. Implementace kontejnerů musí obalit vrstvu jmenného prostoru kolem každého globálního zdroje jádra, a těch je hodně: procesy, souborové systémy, pravidla firewallu, dokonce i systémový čas. Nalezení cest, jak obalit všechny tyto zdroje způsobem, který by splňoval požadavky všech možných kontejnerových projektů, a zároveň neotravoval vývojáře jádra, které kontejnery nezajímají, je docela obtížné.

Plná podpora kontejnerů bude zase blíže, až vyjde verze 2.6.24. Začlenění mnoha důležitých patchů zaplní několik důležitých mezer, i když ještě bude potřeba některé věci dodělat.

Kontrolní skupiny

Bylo nebylo, objevil se patchset nazvaný kontejnery procesů. Subsystém kontejnerů administrátorovi (nebo administrátorskému démonu) umožňuje seskupit procesy do hierarchií kontejnerů; každá hierarchie je spravována jedním nebo více "subsystémy". Původní název "kontejnery" byl chápán jako příliš obecný - jde o důležitou část kontejnerového řešení, ale ani zdaleka to není vše. Takže kontejnery teď byly přejmenovány na "kontrolní skupiny" (nebo "cgroups") a začleněny do 2.6.24.

Kontrolní skupiny však není nutné používat jen pro kontejnery; například funkce skupinového plánování (také začleněna do 2.6.24) používá kontrolní skupiny k nastavování plánovacích hranic. Ale dává smysl spárovat kontrolní skupiny se správou různých jmenných prostorů a správou zdrojů obecně, aby se vytvořil framework pro implementaci kontejnerů.

Správa kontrolních skupin je přímočará. Administrátor systému začne připojením speciálního souborového systému cgroup, přičemž při připojení k němu přiřadí příslušné subsystémy. Těchto souborových systémů může být najednou připojeno více - za předpokladu, že je každý subsystém v maximálně jedné kontrolní skupině. Takže administrátor může vytvořit třeba jeden souborový systém cgroup pro správu plánování a úplně jiný pro přiřazení procesů ke jmenným prostorům.

Jakmile je souborový systém připojen, vytvoří se specifické skupiny (stačí vytvořit podadresáře v rámci souborového systému cgroup). Přidání procesu do kontrolní skupiny se provede obyčejným zapsáním ID daného procesu do virtuálního souboru tasks v cgroup adresáři. Procesy lze mezi kontrolními skupinami libovolně přesouvat.

Jmenné prostory pro PID

Koncept ID procesu se však trochu zkomplikoval, protože byl také začleněn kód jmenného prostoru pro PID. Jmenný prostor pro PID je pohled na procesy v systému. Na "normálním" linuxovém systému je pouze jeden globální jmenný prostor pro PID, kde lze nalézt všechny procesy. Na systému se jmennými prostory pro PID mohou mít různé procesy velmi rozdílné představy o tom, co na systému vlastně běží. Když se vytvoří jmenný prostor pro PID, je viditelný jen ten proces, který ten prostor vytvořil; stane se z něj vlastně init proces daného jmenného prostoru. V novém jmenném prostoru budou viditelní všichni potomci toho procesu, ale nikdy neuvidí věci, které běží mimo daný jmenný prostor.

Tento způsob virtualizování ID procesů dost věcí komplikuje. Proces, který vytvoří jmenný prostor, zůstává viditelný pro svého předka ve starém jmenném prostoru - a v každém jmenném prostoru může mít jiné ID. Takže procesy mohou mít více než jedno ID a stejné ID procesu může popisovat různé procesy v různých jmenných prostorech. V implementacích kontejnerů je poměrně běžné, že proces init má ve svém jmenném prostoru ID 1.

To znamená, že ID procesů mají význam jen v případě, že jsou brány v určitém kontextu. A to zase znamená past na jakýkoliv jaderný kód, který s ID procesů pracuje; všechen takový kód si musí dávat pozor, aby neztratil přehled o zařazení ID procesu do jmenného prostoru, ve kterém je definováno. V rámci snahy o zjednodušení (a také kvůli bezpečnosti) pracují vývojáři kontejnerů na odstranění (do největší možné míry) používání ID procesů v jádře. Jaderný kód by měl pro odkazování na specifické procesy používat ukazatele task_struct (které jsou vždy jednoznačné); z ID procesu tak bude jen cookie pro komunikaci s uživatelským prostorem a nic moc více.

Tohle odstraňování používání PID ještě není dokončeno. Ve skutečnosti je toho ještě potřeba v oblasti jmenných prostorů pro ID procesů udělat hodně. A to do té míry, že to někteří vývojáři vůbec nepovažují za připravené k použití. Především existují obavy, že by se ještě mohlo měnit API, což by rozbilo kód psaný pro API v 2.6.24. Přidávání nových uživatelských API je v tomto ohledu vždy problematické: správně navrnout API je těžké; a správně ho navrhnout už napoprvé, to je ještě těžší. Ale uživatelská API by měla být po začlenění beze změny; neexistuje žádné stabilizační období, během kterého by se věci mohly měnit. U jmenných prostorů PID pravděpodobně dojde k tomu, že bude API označeno jako "experimentální" v naději, že jej nikdo v současné podobě nebude používat.

Síťové jmenné prostory

Do 2.6.24 byl také začleněn patch se síťovými jmennými prostory. Snahou je umožnit procesům v každém jmenném prostoru úplně odlišný pohled na síťový stack. To zahrnuje dostupná rozhraní, směrovací tabulky, pravidla firewallu atd. Patche jsou zatím v relativně raném stadiu; přidávají infrastrukturu pro sledování různých jmenných prostorů, ale nic moc dalšího. Změnilo se docela dost interních síťovacích API, aby akceptovala parametr označující jmenný prostor, ale ve většině případů kód nezvládne žádnou operaci mimo základní, rootovský jmenný prostor. Přibylo virtuální síťové zařízení "veth", které je možné použít k vytvářní tunelů mezi jmennými prostory.

Patche se síťovými jmennými prostory a jmennými prostory pro PID přidaly dvě řádky do <linux/sched.h>:

    #define CLONE_NEWPID   0x20000000   /* Nový jmenný prostor pid */
    #define CLONE_NEWNET   0x40000000   /* Nová síťový jmenný prostor */

Tyto položky připomínají zajímavý problém: příznaky CLONE_ jsou jádru předávány jako 32bitová hodnota. V současné době tak pro nové příznaky zbývají už jen dva bity. Vývojářům kontejnerů tedy dojdou příznaky; jak se s tím chtějí poprat, to zatím není jasné.

hijack()

Vývojáři také pracují na správě kontejnerů a především na tom, jak se pohybovat mezi nimi. Z této práci pravděpodobně v blízké budoucnosti vzejde návrh na nové systémové volání:

    int hijack(unsigned long clone_flags, int which, int id);

Toto systémové volání se chová podobně jako clone(), protože vytvoří nový proces - ale s jedním zajímavým rozdílem. Nový proces vytvořený pomocí clone() bere všechny své zdroje - včetně jmenných prostorů - z volajího procesu; tyto procesy budou zkopírovány nebo sdíleny podle parametru clone_flags. Volání hijack() však místo toho převezme všechny zdroje procesu, jehož ID je udáno parametrem id. Je tedy možné napsat malý program, který se rozdělí [fork] pomocí volání hijack() a spustí shell ve výsledném procesu; takový shell poběží se všemi jmennými prostory "uneseného" procesu.

Aby se lidem s kontejnery lépe pracovalo, byl do API nedávno přidán parametr which. Předá-li se do which 1, považuje volání parametr id za ID procesu, jak je popsáno výše. Hodnota 2 říká, že id je otevřený popisovač souboru pro soubor tasks v adresáří cgroup. V takovém případě najde hijack() vedoucí proces dané kontrolní skupiny a zdroje získá odtud.

Toto systémové volání je nové a zatím se mu nedostalo moc kontroly mimo konferenci o kontejnerech. Je tedy docela možné, že jakmile začne být trochu více na očích, budou požadovány nějaké změny; mimo jiné by mohlo být voláno po změně názvu. Obecně vzato zbývá ještě s kódem kontejnerů udělat hodně práce, ale nějaký pokrok tu zjevně je.

       

Komentáře

[Jan Kundrát (jkt)]

Kvalifikace nejsou jedná sada bitů -> "jedna"

[Filip Jirsák]

Spíš „jediná“, ne?

[Filip Jirsák]

Beru zpět, to by tam bylo „jedinou sadou“. Takže opravdu „jedna“. Občas by člověk uvítal možnost editovat nebo mazat své komentáře, aby nebyl za blbce

[atan]

Na kontejnery se tesim.

ps: hosztitele

[trekker.dk]

Aktuální předverze je (k 31. 10. 2007) i nadále 2.6.24-rc1. Do hlavního repozitáře proudí opravy (včetně japonského překladu dokumentu SubmittingPatches), ale -rc2 zatím ještě nevyšla.

Protože Linus zachrápal a zapomněl ji vydat...

[Marián Kyral]

Jak si to tak čtu, tak asi ještě nějakou dobu zůstanu u 2.6.22-r8. Ve verzi 2.6.23 je nějaký bug, který se minimálně jednou denně projeví totálním zásekem. Ani ledky neblikají a v messages nic není. A když se teď sloučí x86 a x86_64, tak tam těch bugů bude asi více

[Robert Krátký]

ledky neblikají

Tak tohle mi také vrtá hlavou - a nemám ani 2.6.23 (2.6.22-3-amd64 z Debianu). Po nějakém upgradu mi přestaly reagovat ledky na klávesnici. Všiml jsem si toho až po nějaké době, takže ani nevím, co to způsobilo. Navíc mě to nijak moc netrápí, takže jsem zatím po příčinách nepátral. Pokud byste však někdo věděl, o co jde, podělte se.

[Marián Kyral]

Že by známá chyba v xorg 7.3? https://bugs.freedesktop.org/show_bug.cgi?id=12434

Jen jsem netušil, že to zasáhne i kernel panic

[trekker.dk]

Zajímalo by mě, jak taková chyba mohla vzniknout. To si nikdo z vývojářů nevšiml, že se mu nepřepínají ledky?

[Marián Kyral]

Člověk to tak dlouho testuje, až je z toho úplně zblblý a když už konečně vydá finální verzi, tak je tam takováhle dost podstatná drobnost... Jistý Murphy o tom popsal stohy papíru

[trekker.dk]

Jo, pak to sepsal do knihy a když dostal do ruky první výtisk z tiskárny, na první stránce, kterou otevřel, našel chybu

[Robert Krátký]

Vida, díky za link. Zvláštní je, že když jsem zkoušel num/caps-lock během startu systému, přestaly ledky fungovat už chvíli před spuštěním X serveru...

[Michal Vyskočil]

To bude ta technologie přednačítání. Jak vidět, funguje i na bugy

[Oskar]

Asi to nemá cenu, ale přesto:

"Control Groups" rozhodně neznamená "Kontrolní Skupiny". Kdyby se autor obtěžoval podívat do slovníku, zjistil by, že "Control" znamená "řídit", "ovládat", ale nikdy ne "kontrolovat", na to jsou v angličtině slova jako check, nebo test.