Jaderné noviny – 11. 2. 2015: Začleňovací okno 3.20 je otevřeno

10. 6. 2015 | Redakce | Jaderné noviny | 2359×

Stav vydání jádra. Citát týdne. Začleňovací okno 3.20 je otevřeno.

Stav vydání jádra

Kernel 3.19 byl vydán 8. února (oznámení). Linus: "I když jsem měl několikrát nutkání udělat rc8, nakonec pro to nebyl důvod." Významné změny ve vrzi 3.19 zahrnují podporu procesorů Altera Nios II, podporu překrytí stromu zařízení, možnost připojit programy eBPF k soketům, mazání disku, náhradu za RAID 5 a 6 v souborovém systému Brtfs, systémové volání execveat () a mnoho dalšího.

Začleňovací okno pro další vývojový cyklus je nyní otevřeno, viz. články níže.

Stabilní aktualizace:3.18.6, 3.14.32 a 3.10.68 byly vydány 6. února. Následovaly 3.18.7, 3.14.33 a 3.10.69 11. února.

Citáty týdne

Někdy jsou zařízení až příliš rychlá. Nebylo by skvělé, kdybychom mohli (1) mít možnost přistupovat k nim nejklasičtějším způsobem a (2) zajistit, aby i běžné případy způsobily zbytečnou zátěž navíc? Konec čekání, tento patch to umí!

-Rusty Russel

Ukazuje se, že patche jsou jako spam nebo štěňátka. Cení si jich ti, kdo je tvoří, ale s podezřením se na ně dívají maintaineři.

-Paul McKenney

Začleňovací okno 3.20 je otevřeno.

Začleňovací okno 3.20 se otevřelo 8. února s vydáním kernelu 3.19. V době psaní tohoto článku bylo do hlavního repozitáře zahrnuto na 3600 neslučitelných sad změn. Mezi nejzajímavější a nejviditelnější patří:

• Bylo začleněno jádro nového mechanismu pro live patching. Jeho úkolem je podporovat jak kGraft, tak kpatch, ale bude třeba něco dodělat, aby to fungovalo jak má. Kernel však už nyní zvládá live aplikace jednoduchých bezpečnostních oprav. Více informací najdete v začleňovacím zápisu, příklad jednoduchého live patche v tomto zápisu.
• Kernel může být sestaven pro spouštění read-copy-update (RCU) grace-period-handling vláken s prioritami v reálném čase. Většina systémů to nevyužije, ale některým silně zatíženým systémům by to mohlo pomoci.
• Jak jsme psali minulý rok, implementace systémového volání remap_file_pages() byla odstraněna. Místo něj je funkce, která emuluje stejnou funkcionalitu za použití několika oblastní virtuální paměti, takže těch několik málo aplikací, využívajících toto volání, by mělo i nadále fungovat.
• Nástroj pro sledování výkonu se dočkal celé řady změn, pro jejich seznam se podívejte na changelog v zápisu
• Síťový zásobník nyní podporuje aplikace se specifickým algoritmem pro kontrolu zahlcení sítě na základě jednotlivých počítačů skrze směrovací tabulku. Tento patch obsahuje dokumentaci, kde je vidět, jak nové ip route commands fungují.
• Implemtace síťového zásobníku TIPC je nyní namespace-aware.
• Subsystém řízení provozu nyní podporuje aplikování filtrů, vytvořených ve virtuálním stroji eBPF (rozšířený filtr paketů Berkeley).
• Subsystém Open vSwitch nyní může generovat svá vlastní "flow ID" pro identifikaci síťových toků v uživatelském prostoru řízeného provozu. Tato změna může zvýšit výkon některých operací o 40 %.
• Podpora nového hardwaru zahrnuje:


• Audio: Zvukové karty Studio Evolution SE6X, procesory Intel Cherrytrail a Braswell s kodeky RT5645, desky Nvidia Tegra s kodeky RT5677.
• Input: Zařízení se zpětnou vazbou Betop Production Inc., tablet Allwinner sun4i, tlačítka TI TPS65218, X-Powers AXP20X, NI Ettus Research USRP E3x a ovladače Allwinner A10 PS/2.
• Různé: Adaptéry Diolan DLN USB-SPI, ovladače STMicroelectronics SSC SPI, regulátory Maxim 77843, MediaTek MT6397 PMIC, řadiče pamětí Synopsys DDR, Fujitsu Semiconductor F_SDH30 SDHCI, měřidla baterií Richtek RT5033, nabíječky Maxim MAX77693, ukazatele LTC2941/LTC2943 a analogové zesilovače TI OMAP OPA362.
• Sítě: Řadiče Rockchip SoC RK3288 10/100/1000, HISILICON P04, subsystémy TI Keystone NETCP, rozhraní Kvaser USBcab II CAN a PEAK PCAN-USB/USB Pro CAN-FD.
• SCSI: Qualcomm UFS PHY
• Video4Linux: Zařízení pro nahrávání videa TI AM437x VPFE, dekodéry Philips RC5/RC6, USB kamery Touptek.

Mezi změny viditelné pro vývojáře jádra patří:

• (Sleepable) RCU subsystém je možné vyřadit z kompilace jádra a ušetřit tak trochu místa tam, kde není zapotřebí.
• Funkce ladění might_sleep() bude nyní sledovat přetečení zásobníku při problémech. To, co často vypadá jako nevhodné volání funkce sleep, bývá ve skutečnosti artefakt, způsobený přetečením zásobníku.
• Nový mechanismus devfreq nabízí způsob, jakým je možné získat surová data o výkonu a využití zařízení.

Několik věcí je třeba mít v souvislosti se zbytkem začleňovacího okna na paměti. Jednou z nich je, že podle linux-next maintainera Stephena Rothwella, by toto vydání mohlo být na dlouhou dobu nejmenší. Repozitář obsahuje maximálně 8000 sad změn; vydání před 3.19 jich obsahovalo téměř 11 000. Takže by to mohlo skončit jako relativně klidný cyklus

Tou další je, že je zde stále možnost, že se výsledný kernel nebude jmenovat 3.20. V roce 2013 Linus navrhoval, aby se kernel po 3.19 přejmenoval na 4.0. Podobně jako v případě 3.0, by tato změna neměla žádný speciální význam, jde jen o to, že se Linus nechce vracet k "číslování vydání, při kterých bych si musel sundat ponožky, abych do tolika napočítal." O změně názvu nedávno nic neříkal, ale změna by mohla nastat kdykoli v následujících týdnech. Zůstaňte na příjmu.

Dědící schopnosti

Schopnosti Linuxu byly dlouho brány jako možnost, jak se vyhnout setuid programům, i když realita je ve skutečnosti jiná. I když rozdělování pravomocí roota do odlišných drobných oprávnění má jisté koncepční výhody, implementace trpí řadou nedostatků, které ztěžují, například možnost využití ping a dalších nástrojů bez použití setuid root. Ve skutečnosti bylo používání schopností vždycky složité a jsou zde také základní omezení, která se občas dají obejít neoficiálními záplatami. Na nedávné kernelové emailové konferenci se řešilo jedno z omezení modelu schopností, s důrazem na jeho odstranění.

Podle současného modelu nemohou procesy jednoduše předat své schopnosti jiným programům skrze volání execve() tak, jako jsou jiná oprávnění poděděná. Christoph Lameter zveřejnil patch, který by umožnil administrátorům specifikovat, které schopnosti mají být zděděny programy skrze execve(). Smyslem je povolit privilegovaným programům bez setuid root vytvořit další programy s omezenými privilegii - přesně ten typ dovedností, který by schopnosti měly poskytovat.

Na linuxové schopnosti jsme se během let dívali několikrát, často v kontextu nového přístupu k řešení některých nedostatků v současném modelu Linuxových schpností (který je odvozen od zaniklé verze POSIX). Například schopnosti založené na souborech byly přidány proto, aby mohly využívat rozšířené atributy (xattrs) na programových souborech k ukládání schopností tak, aby tyto schopnosti byly poskytnuty programům, ve chvíli spuštění. Tímto byl schopnosti CAP_SETPCAP navrácen její původní smysl, což poskytlo administrátorům možnost udělovat schopnosti individuálním programům (namísto běžícím procesům). Zaznamenali jsme další problémy, v jistém smyslu je tento článek pokračováním tohoto trendu.

Lameter popsal jeho zkušenost s použitím patche. Spouští síťový zásobník v uživatelském prostoru, který vyžaduje privilegia k surovému přístupu k síti, ale také může běžet na libovolném binárím programu. Rád by omezil co tyto programy mohou dělat, ale potřebuje, aby měly jistou podmnožinu rootových oprávnění. Toho se dá docílit pomocí setuid programů, ale ty by rád omezil tak, aby nezískaly všechna rootova oprávnění.

Článek LWN z roku 2006, ke kterému Lameter odkazoval ve svém příspěvku popisuje základy schopností. Zejména se dívá na různé sady schopností a to, jak mohou být kombinovány k určení, které schopnosti proces má.

Tento první Lameterův patch dává administrátorům možnost určit globálně, které schopnosti mají být zděděny skrze execve(). Čísla schopností by bylo možné zapsat do souboru sysf, čímž by tyto schopnosti mohly být zděděny kterýmkoli novým programem, pokud je volající execve() vlastnil. Formu tohoto patche používá již šest let, ale byl by rád, kdyby se tento patch (nebo něco, co by řešilo stejný problém) dostal upstream, takže by ho již nemusel mít ve svých kernelech.

Obvyklý způsob jak spustit binární program s nějakou schopností je vložit tuto schopnost do "povolených" a "efektivních" nastavení binárního souboru za použití schopností soborových xattrs. Tímto způsobem budou mít binární soubory tyto schopnosti vždy, ale, což nemusí být žádoucí - obzvláště pro systémové binární soubory. Bez vložení souborových schopností do několika různých binárních souborů v celém systému, není způsob jak předat CAP_NET_RAW (nebo jiné např. CAP_NET_ADMIN či CAP_SYS_NICE) podřízeným procesům či novým programům s spuštěným s execve(). Vzhledem k tomu, že v Lameterově případě je přítomno skriptování, bylo by nezbytné dát interpretovacím jazykům (např. Bash, Python), jakékoli schopnosti, které skripty vyžadují, což by zcela jistě nevedlo k bezpečnějšímu systému.

Vypadá to jako zásadní omezení Linuxového modelu schopností, ale stěží je první. Části schopností byly v průběhu let libovolně vybírány vývojáři kernelu bez větší koordinace. To vedlo k náhodnému vybírání schopností, jako je CAP_SYS_ADMIN, která je vlastně totožná s funkcí root (i když jsou ještě další, u kterých to platí také). O Linuxovém modelu schopností je možné říci mnohé, koherence při jeho navrhování a provádění ovšem není příliš patrná.

Lidé, kteří by této funkcionality rádi využívali, neustále narážejí na překážky, které jim v tom brání. Jak si postěžoval jeden z vývojářů schopností, Serge Hallyn, stále není možné nastavit schopnost pinguse (spíše než setuid) jako výchozí. Je to tím, že některé souborové systémy nepodporují xattrs, což platí také pro některé nástroje, jako je třeba starší verze tar nebo současné verze cpio (i když na změně se pracuje).

Ovšem globální povaha v nastavení dědičnosti Lameterovy sady patchů nebyla oblíbená. Jak Hallyn, tak Andy Lutomirsky navrhovali způsoby, jak udělat nastavení pro proces nebo pro uživatelský jmenný prostor. Hallyn navrhoval přidání "dědičných sad v prostředí", které by se zkombinovaly s dědičnými sadami takovým způsobem, který by byl analogický k sadě omezující povolené schopnosti. Lutomirsky měl za to, že jeden bit by mohl sloužit k tomu, aby řekl, že všechny soubory mají být brány tak, jako by měly plnou sadu schopností ve svých zděděných sadách, což by v podstatě mělo stejný účinek.

Ale Casey Schaufler měl námitky k myšlence, že Lameterovo použití bylo přiměřené z bezpečnostního hlediska. "Použitím takového programovacího modelu se dostáváte do příliš zlomkovitého území v prostředí, které vyžaduje zabezpečení." I když reagoval také na to Lameterovo tvrzení o "nepořádku schopností", který je třeba uklidit:

"Jsem pro pokračovat v tomto úsilí. Schéma POSIX je funkční, ale vzhledem k tomu, že je 20 let staré a nevyvinulo si širší záběr, je těžké mluvit o úspěchu."

Ohledně zlepšení schopností proběhlo několik diskuzí, ale, jak poznamenal Lutomirski, žádné z nich neřeší podstatu problému. "Jestliže mám schopnost a chci ji předat pomocnému programu přes exec, měl bych se obejít bez pomoci fs´s." Na tom se sice všichni shodli, ale Hallyn poukázal na to, že použití souborového systému k umisťování schopností na binární soubory, je totožné s fungováním schopností POSIX.

Jedná zajímavá poznámka mimo téma je ta, že Lameter není jediný, kdo používá dědičné schopnosti v produkci: Telefon N9 na bázi MeeGo od Nokie je využívá také.

Po diskuzi Lamter obrátil a zveřejnil RFC patch, který implementoval Hallynův návrh na okolní sadu schopností. tento návrh se setkal s několika námitkami. Začněme tím, že přidávání schopností k okolním sadám by nemělo povolit schopnosti, které nejsou v povolené sadě procesu, řekl Lutomirski. Dále navrhl, že přidávání schopností okolním sadám by mělo vyžadovat o něco více, než jen schopnost CAP_SETCAP. Vyžadováním PR_SET_NO_NEW_PRIVS (viz. tento článek a Documentation/prctl/no_new_privs.txt), by neměl execve() přidávat žádné další privilegia, což by bylo mnohem pohodlnější. Což by ale "učinilo tento patch zbytečným", protože programy, které vyžadují více privilegií (např. setuid root), je třeba někdy spustit, řekl Lameter.

Vzhledem k Lameterovu použití, by se využití PR_SET_NEW_PRIV zdálo neprůchozí, ale ostatní námitky Lutomirského a Hallyna adresoval v první verzi svého patche. V této verzi mohou být okolním sadám předávány pouze schopnosti, které jsou povoleny. Navíc mohou procesy vymazat své povolené sady a ujistit se, že žádné nové schopnosti nebudou poskytnuty potomkům nebo programům běžícím skrze execve(), na základě obsahu okolní sady. To byla jedna z hlavních obav, které se týkaly patche RFC.

Jak již bylo řečeno ve vláknech, existuje velký počet překážek, které brání použití schopností v Linuxových systémech. Jsou složité pro přemýšlení, obsahují API, které se obtížné používat a v průběhu let byly nedůsledně aplikovány. To všechno je sice nešťastné, ale je velmi nepravděpodobné, že by jakékoli hnutí za jejich odebrání a nový začátek získalo nějakou podporu. Schopnosti jsou součástí jaderného ABI a je pravděpodobné, že s námi zůstanu navždycky, ať je chceme nebo ne. Změny jako okolní sady nemusí zmírnit složitost, ale mohou pomoci použitelnějšímu funkčímu systému kupředu.

       

Komentáře

[Michal Kubeček]

Když už překládat congestion control, tak control v tomto případě (jako ostatně i ve většině jiných) znamená spíš řízení nebo ovládání, ne kontrola.

[Filip Jirsák]

Schopnosti Linuxu byly dlouho brány jako možnost, jak se vyhnout setuid programům, i když realita je ve skutečnosti jiná.

Z téhle věty vůbec není jasné, že se jedná o jednu konkrétní technologii „Linux capabilities“ (tj. rozdělení rootovských práv na menší části) a ne obecně o všechny schopnosti/vlastnosti/možnosti Linuxu. A zkusil bych to překládat jiným slovem, než „schopnost“, třeba „kvalifikace“ by se podle mne hodila lépe. „Linuxové kvalifikace (capabilities) byly dlouho brány…“. Doufám tedy, že termín „kvalifikace“ není v oblasti kolem linuxových oprávnění už obsazen.

[mimi.vx]

a nebo jeste lepe technicke a bezne pouzivane terminy neprekladat

[Filip Jirsák]

S tím nesouhlasím. Myslím, že Jaderné noviny bývaly prostorem, kde se hledaly překlady pro nové termíny, a bylo to dobře. Drtivá většina (původně) termínů v češtině je přeložených nebo počeštěných. Když byly nové, někdo možná používal originál, zkoušely se různé překlady nebo počeštění, a některá z variant se ujala. Kdybychom se dnes rozhodli, že termíny (které často postupně přecházejí do obecného jazyka) přestaneme překládat, budeme mít v jazyce čím dál víc cizích slov, a místo češtiny budeme čím dál víc mluvit pidžin. Bude nám chybět ohýbání cizích slov, takže budeme sdělení zjednodušovat, aby byla pochopitelná i bez toho... Raději desítky nepovedených překladů, ze kterých se pak vyloupnou ty povedené, než jazyk takhle zmrzačit. Samozřejmě to vyžaduje určité dovednosti, pokud překladatel bojuje s obecnou angličtinou, jeho příspěvky k překladům nových termínů asi málokdy budou hodnotné.

[Ovrscout]

S druhým extrémem, překladem do "čisté" češtiny za každou cenu, zas nesouhlasím já. To už radši zaveďte úplně nové slovo, třeba takové "xbdzyv" je tuším volné :) Když překlad neodpovídá významu originálu (např proto že by se nevešel do jednoho slova atp.) tak se text stává zavádějícím. Obzvlášť když dáváme nějakému existujícímu slovu jiný nebo pozměněný význam. To už raděj tu capabilitu než schopnost. Ale můžete mít jiný názor, jak jste psal, nakonec se uvidí co se ujme.

Každopádně by bylo fajn kdyby byl u nově zaváděného,nebo né běžně zažitého "termitu" byl i odkaz na originální/standardní termín, třeba v závorce. Nebo případně i s drobným českým popisem co tím básník chce říci.

Nosočistoplenám zdar!

[Filip Jirsák]

Souhlasím. Nechci jen překládat do současných českých slov – klidně vymyslet slovo nové, opsat frází nebo počeštit cizí slovo. Ale nenechávat v textu cizí termín, se kterým se v češtině nedá nic dělat. Souhlas i s tím, že je dobré u prvního použití v textu uvést originální termín v závorce.

[Michal Kubeček]

Překládat má smysl termíny, které používá široká veřejnost, takže se dá očekávat, že se budou běžně vyskytovat v českém textu. Překládat úzce odborné termíny, které používá jen úzká skupina odborníků a v drtivé většině je stejně používá při komunikaci v angličtině, je nesmysl a ve výsledku to jen mate. Viz třeba ta věta o per-route congestion control algoritmech: přestože jsem zrovna předevčírem dělal backport právě těchto patchů, musel jsem nad ní přemýšlet, než mi došlo, že je řeč zrovna o tom. Nerad bych se dožil toho, že tu budu číst o průhledných obrovských stránkách nebo přenosovém protokolu řízení proudů.

[Filip Jirsák]

Jenže každý termín, který používá široká veřejnost, byl na začátku úzce odborný termín. A je potřeba ho začít překládat v té době, kdy je to ještě úzce odborný termín. Když už to začíná používat široká veřejnost, je pozdě – navíc široká veřejnost si nejspíš v takovém případě vymyslí vlastní překlad, který bude špatně. Bohužel se nedá dopředu říci, které termíny začne používat široká veřejnost – před 40 lety to vypadalo, že všechny (dnešními slovy) IT termíny budou jen pro úzkou skupinu odborníků. U nových překladů by původní termín měl být uveden v závorce, protože je dost pravděpodobné, že text bude číst někdo, kdo originální termín zná. Ale jinak si myslím, že Jaderné noviny jsou ideální místo, které by mělo fungovat jako laboratoř pro nové termíny – protože když je nevymyslíme my tady, vymyslí je za pár let nějaký elév v MF Dnes, až bude překládat nějaký agenturní článek.

[HonzaRez]

Jeden z nejklasičtější termitů u široké veřejnosti, je "četování". Oni nevědí, že ve skutečnosti žvanili...

[Michal Kubeček]

Bohužel se nedá dopředu říci, které termíny začne používat široká veřejnost – před 40 lety to vypadalo, že všechny (dnešními slovy) IT termíny budou jen pro úzkou skupinu odborníků.

U některých, které překladatelé JN ve svém svatém nadšení překládají, bych se klidně vsadil, že se to nestane - a to skoro nesázím.

protože když je nevymyslíme my tady, vymyslí je za pár let nějaký elév v MF Dnes, až bude překládat nějaký agenturní článek.

Představa, že vymýšlením vlastních překladů na ABCLinuxu tomu lze zabránit, mi připadá hodně naivní. Když Microsoft přišel se svými "nabídkami", "složkami" a "klepáním", odborná veřejnost už dávno používala menu, soubory měla v adresářích a myší klikala. A bylo nám to něco platné?

[kyknos]

s nabídkami a složkami určitě nepřišel MS ale Apple

[rADOn]

V čem by byl novinářský elév horší než mechanický překladač na webu který nemá ani na korektora? Vymýšlet slova si může dovolit někdo kdo má pro jazyk aspoň trochu citu. Autor článku zvládne nejvýše tak překlápět angličtinu do anglikanismů. Nechci ho hanět, naopak, jsem rád že to aspoň někdo překladá, ale není to laborant do tvé "laboratoře pro nové termíny".

V tomto případě to ani nedává smysl protože 'capabilities' nejsou nový termín. V JN se už několikrát vyskytly a jsou součástí terminologie.

[Filip Jirsák]

Vymýšlet slova si může dovolit někdo kdo má pro jazyk aspoň trochu citu. Autor článku zvládne nejvýše tak překlápět angličtinu do anglikanismů. Nechci ho hanět, naopak, jsem rád že to aspoň někdo překladá, ale není to laborant do tvé "laboratoře pro nové termíny".

To je bohužel pravda. Ale bývali tu jiní překladatelé, kteří na to vymýšlení nových termínů měli. Takže podle současného překladatele nelze vytvářet pravidlo "cizí termíny nikdy nepřekládat". No a u pravidla "cizí termíny nikdy nepřekládat, pokud to překladatel neumí" je otázka, zda takový překladatel vůbec má překládat.

To, že "capabilities" ještě nikdo dobře nepřeložil, neznamená, že se o to nemáme pokoušet. Právě naopak. A to, že se tu ten termín vyskytuje opakovaně, naznačuje, že by nemusel zajímat jen pár lidí zajímající se o vnitřnosti jádra. Třeba se za pár let běžně bude vyskytovat v článcích pro začátečníky "jak spustit svůj první webový server", a jejich čtenáři nebudou zvědaví na to, aby se jim v českém textu objevovalo slovo "capabilities".

[kdave]

'Capability' se tradičně překládá jako 'bumážka'.

[Jendа]

jde jen o to, že se Linus nechce vracet k "číslování vydání, při kterých bych si musel sundat ponožky, abych do tolika napočítal."

Počkat, to umí bez sundání ponožek udělat 19? Kolik má prstů? Nebo počítá binárně, ale to by bez ponožek dal 1023.

[koudy]

Na 2 rukách se dá napočítat do 30

1 ruka jako klasický čítač, 2. jako čítač přetečení té první.

To binární počítání na prstech není asi úplně intuitivní (myslím pro všechny ostatní kromě IT lidí) :)

[Honza Jaroš]

Zkusil jsem si to a došel jsem ke 35. Buď dělám někde chybu, nebo je 30 špatná hodnota. Nebo mám moc prstů...

[koudy]

Pokud beru 1. ruku jako čítač přetečení tak je maximum:

5 * 5 (cítač přetečení) + 5 (2. ruka) = 25 + 5

Aaa už jsem se chytil: Vy to berete v 6 soustavě? to znamená 6*5 + 5?

Možná to tak má větší logiku (a asi to popisuje přesněji to co jsem psal výš a tímto se omlouvám, za nepřesný popis, chtěl jsem jen ukázat že to jde) :)

Trošku blbě se to vysvětluje lidem co mají problémy i s běžným počítáním na prstech, kdybych na ně vyrazil ještě se 6 soustavou, tak jsou úplně ztracený ;)

[Honza Jaroš]

No přesně, ruka sevřená v pěst je taky číslo, čili na jedné ruce jde udělat šest hodnot.

[Jendа]

Já intuitivně na rukou dokážu reprezentovat čísla 0-12 (palec se dotýká článků ostatních prstů).

Kromě neintuitivity se některé binární hodnoty špatně nastavují.

[Jendа]

(na každé ruce 0-12)

[pc2005]

Vida, tak to Topolánek Kalouskovi oznamoval, že je čtyřka vlastně .

[Hans1024]

Nebo počítá binárně, ale to by bez ponožek dal 1023.

To by byla hlavne sranda u verze 132

[Jendа]

Linus announcuje verzi 4.0

[Hans1024]

[little.owl]

jde jen o to, že se Linus nechce vracet k "číslování vydání, při kterých bych si musel sundat ponožky, abych do tolika napočítal."

A kdyz si sunda trenyrky, tak bude mit jeste na jeden release ...

[pc2005]

Ten ale nebude dlouhodobě stabilní .