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).
Provozovatel čínské sociální sítě TikTok dostal v Evropské unii pokutu 530 milionů eur (13,2 miliardy Kč) za nedostatky při ochraně osobních údajů. Ve svém oznámení to dnes uvedla irská Komise pro ochranu údajů (DPC), která jedná jménem EU. Zároveň TikToku nařídila, že pokud správu dat neuvede do šesti měsíců do souladu s požadavky, musí přestat posílat data o unijních uživatelích do Číny. TikTok uvedl, že se proti rozhodnutí odvolá.
Společnost JetBrains uvolnila Mellum, tj. svůj velký jazykový model (LLM) pro vývojáře, jako open source. Mellum podporuje programovací jazyky Java, Kotlin, Python, Go, PHP, C, C++, C#, JavaScript, TypeScript, CSS, HTML, Rust a Ruby.
Vývojáři Kali Linuxu upozorňují na nový klíč pro podepisování balíčků. K původnímu klíči ztratili přístup.
V březnu loňského roku přestal být Redis svobodný. Společnost Redis Labs jej přelicencovala z licence BSD na nesvobodné licence Redis Source Available License (RSALv2) a Server Side Public License (SSPLv1). Hned o pár dní později vznikly svobodné forky Redisu s názvy Valkey a Redict. Dnes bylo oznámeno, že Redis je opět svobodný. S nejnovější verzí 8 je k dispozici také pod licencí AGPLv3.
Oficiální ceny Raspberry Pi Compute Modulů 4 klesly o 5 dolarů (4 GB varianty), respektive o 10 dolarů (8 GB varianty).
Byla vydána beta verze openSUSE Leap 16. Ve výchozím nastavení s novým instalátorem Agama.
Začleňovací okno 2.6.29 je otevřené, takže v době psaní tohoto článku není žádná vývojová verze jádra. Do 2.6.29 byl začleněn docela velký kus práce; detaily vizte v samostatném článku níže.
Současné stabilní jádro 2.6 je 2.6.28, vydané Linusem 24. prosince. Mezi nejvýznamnější změny v tomto jádře patří přidání správce GPU paměti GEM, souborový systém ext4 již není "experimentální", zlepšení škálovatelnosti ve správě paměti pomocí přepracovaného vmap() a patchů škálovatelnosti odstraňování stránek, přesunutí ovladačů -staging do hlavní řady a mnoho dalších. Spoustu dalších detailů o 2.6.28 vizte ve skvělém shrnutí na KernelNewbies. Linus říká: Dokonce i když máte přátele nebo rodinu, nechte je jejich nekončícímu pachtění se s vánočním řízkem nebo kaprem a během noci, až budou spát, jim můžete nadělit kouzelný dárek nově aktualizovaného počítače. Až se zítra ráno probudí, řekněte jim, že jste viděli Ježíška s USB diskem v ruce, jak aktualizoval OS všech hodných chlapců a děvčat.
-- Alan Cox
-- Linus Torvalds (Díky Jeffu Schroederovi)
-- Ted Ts'o
V době psaní tohoto článku bylo do vývojového cyklu 2.6.29 přijato nějakých 6500 neslučovacích sad změn. Je to obvyklá sada nových ovladačů zařízení společně s mnoha důležitými změnami vnitřku jádra.
V době psaní tohoto článku mezi změny viditelné pro uživatele patří:
Nové ovladače pro:
Mnoho nových ovladačů se do jádra dostalo také přes strom staging; mezi ně patří ovladače pro:
Také byla přidána, zdánlivě bez pomoci Google, sada ovladačů pro platformu Android, včetně podpory pro IPC mechanismus /dev/binder, časované GPIO operace, RAM buffer konzoli - zvláštního zařízení "zabijáka při nedostatku paměti" [low memory killer] - a logovací zařízení
Pamatujte, že "staging" ovladače nejsou považovány za ovladače dosahující kvality jaderného kódu; jsou začleněny s nadějí, že je vývojáři pomohou zlepšit. Přes strom staging bylo tentokrát začleněno poměrně hodně zlepšení těchto ovladačů, takže se zdá, že strom funguje tak, jak bylo zamýšleno.
Po dlouhou dobu zavržený ovladač eepro100 byl konečně odstraněn; místo něj by měl být používán ovladač e100.
SCSI vrstva získala podporu pro zařízení Fibre Channel over Etherner (FCoE).
Kód ovladače GEM vrstvy používané pro správu paměti v jednotkách grafického procesoru (GPU) se dočkal mnoha vylepšení. Velkou novinku v této oblasti je nicméně to, že byl konečně začleněn kód pro jaderné nastavování režimu [kernel mode setting]. Tato změna dláždí cestu pro odstranění velké části děsivého kódu v uživatelském prostoru, lepší podporu pro vlastnosti jako rychlé přepínání uživatelů a schopnost X serveru běžet bez oprávnění superuživatele. Jaderné nastavování režimu je nicméně v počátečním stádiu a většina lidí by ho neměla zapínat, pokud si nebudou jisti, že mají správně připravený uživatelský prostor.
Do kódu architektury arm byla přidána podpora pro systémy HP iPAQ h5000, systémy založené na sérii Samsung S3C64XX a herní konzole Pandora.
Architektura SuperH získala podporu pro sledovací framework ftrace.
Je zde nová boot volba no_file_caps=, kterou lze použít pro zakázání kvalifikací souborů [file capabilities] u jader, která mají tuto vlastnost povolenu. Z changelogu: To distributorům umožňuje dodávat jádro se zakompilovanými kvalifikacemi souborů bez toho, aby byli uživatelé nuceni je používat (a rozumět a důvěřovat jim).
Souborový systém CIFS podporuje novou volbu při připojování forcemand; když je použita, zajistí, že CIFS používá povinné zámky [mandatory locks] místo nepovinných zámků [advisory locks].
V síťové vrstvě jsou nyní podporovány algoritmus omezující TCP zácpu CUBIC 2.3 [TCP congestion control algorithm] a vlastnost "zpětné upozornění na zácpu" [backward congestion notification].
Síťovací kód má nyní podporu pro algoritmus plánování paketů "deficitní round robin", o kterém se tvrdí, že má zajistit vysoce férové plánování s minimálními náklady.
Byla začleněna rozsáhlá sada patchů síťových jmenných prostorů. Vývojáři jmenných prostorů se zatím zdrželi tvrzení, že je tato vlastnost připravena na všeobecné používání, ale musí se tomu blížit.
Souborový systém devpts nyní podporuje vytvoření několika instancí v různých jmenných prostorech.
Kód pro regulaci bezdrátových zařízení podle domény [wireless regulatory domain] byl rozšířen, aby podporoval 802.11d.
Sada patchů stromového RCU, která by měla poskytnout vylepšenou škálovatelnost na systémech s "více než pár sty procesorů", byla začleněna.
Uživatelé velkých stránek se nyní mohou podívat do /proc/pid/smaps na novou hodnotu KernelPageSize, která udává skutečnou velikost stránek, které se používají. Mezi jinými věcmi lze tuto informaci využít pro ověření toho, že proces opravdu využívá velké stránky tam, kde se to očekává.
Souborový systém eCryptfs nyní podporuje šifrování jmen souborů stejně jako jejich obsahu.
Mechanismus souborového systému v uživatelském prostoru FUSE nyní může podporovat volání ioctl() a poll().
Do bezpečnostního modulu SMACK byla přidána podpora pro neoznačené sítě a hostitele.
Změny viditelné pro jaderné vývojáře zahrnují:
Nové synchronní hashovací rozhraní nazvané "shash" zjednodušuje použití synchronních hashovacích operací a přitom umožňuje použít stejné tfm simultánně v různých vláknech. Všichni uživatelé ve stromě byli přepnuti na nové API.
Ohromná sada patchů osobních údajů [credentials] byla začleněna. Tento kód reorganizuje správu osobních údajů procesu (ID uživatele, kvalifikace atd.). Jedním z okamžitých důsledků této změny je to, že přímé odkazování se na pole zaměřená na osobní údaje ve struktuře úlohy musí být změněno; například current->user->uid se mění na current_uid(). Popis nového API vizte v Documentation/credentials.txt.
Kód ftrace se dočkal mnoha interních změn. Sledování funkcí bylo v mnoha ohledech vylepšeno a vývojáři přidali mechanismus pro profilování chování příkazu if, poskytnutí grafu volání funkcí, získání sledování zásobníku v uživatelském prostoru a sledování přechodů mezi stavy napájení.
Většina funkcí/metod zpětných volání spojených se strukturou net_device byla z této struktury přesunuta do nové struct net_device_ops. Ovladače ve stromě byly konvertovány na nové API.
Ze struktury struct net_device; bylo odstraněno pole priv; ovladače by místo něj měly používat netdev_priv().
Obecná PHY vrstva má nyní podporu pro správu napájení. Za tímto účelem byly do struct phy_driver přidány dvě nové metody - suspend() a resume().
Síťová vrstva nyní podporuje operaci odlehčování při rozsáhlém příjmu [large receive offload] (či "obecné odlehčování při příjmu")
API NAPI bylo trochu pročištěno. konkrétně funkce jako netif_rx_schedule(), netif_rx_schedule_pred() a netif_rx_complete() ztratily nepotřebný parametr struct net_device.
Kód časovačů s vysokým rozlišením byl zjednodušen odstraněním proměnných režimů funkcí zpětných volání. Všechno zpracování nyní probíhá v kontextu tvrdého IRQ (hardirq)
Byla přidána nová sada LSM háčků [hooks]; tyto podporují bezpečnostní operace založené na cestách se jménem [pathname]. Se začleněním těchto háčků byla odstraněna jedna hlavní překážka začlenění bezpečnostních modulů jako AppArmor a TOMOYO.
Jádro se nyní odmítne přeložit s GCC 4.1.0 nebo 4.1.1; tyto verze mají nepříjemné chyby, které brání vytvoření funkčního jádra. Verze 3.0 a 3.1 byly také prohlášeny za příliš staré a v 2.6.29 nebudou podporovány.
Ovladače Video4Linux nyní používají oddělenou strukturu v4l2_file_operations, ve které se ukládají jejich jako-VFS zpětná volání. Prototypy mnoha z těchto funkcí byly změněny, byl odstraněn parametr inode.
Video4Linux2 nyní získal koncept "podzařízení", který má odrážet fakt, že video "zařízení" ve skutečností bývá sestava několika spolupracujících zařízení. Popis toho, jak tento mechanismus funguje, vizte v novém dokumentu.
Dvě nové funkce - stop_machine_create() a stop_machine_destroy() - umožňují nezávislé vytváření vláken používané stop_machine(). To umožňuje vytvořit tato vlákna před skutečným pokusem stroj zastavit, čímž je celá operace odolnější proti selhání.
Souborová operace poll() nyní může spát; více informací o této změně vizte v tomto článku.
Mechanismus masek CPU, který se používá k reprezentaci sady procesorů v systému, je uprostřed rozsáhlého přepracování. Problém spočívá v tom, že masky CPU se často ukládají na zásobník, ale s tím, jak počet CPU roste, na zásobníku není pro masku dost místa. Nové API je navrhováno tak, aby tyto masky ze zásobníku zmizely a aby existovala ochrana proti tomu, kdyby se někdo někdy snažil je tam uložit. Detaily o této práci vizte v tomto oznámení od Rustyho Russela.
Začleňovací okno bylo otevřeno 28. prosince; jestliže přetrvá obvyklý dvoutýdenní vzor, změny by měly být přijímány do 11. ledna. Nalaďte si nás příští týden a dozvíte se aktuální informace o posledních patchích začleněných do jádra 2.6.29.
Používání jaderného patche mimo strom má několik nevýhod, ale dokud je patch udržován a aktualizován s jádrem, je to možné. Když vývojáři ztratí zájem - nebo financování - pro uživatele z toho je mnohem větší problém. K tomuto stavu možná dojde pro uživatele nástroje grsecurity, protože nedávné vydání přichází s varováním, že by mohlo být poslední.
Není překvapivé, že uživatelé grsecurity mají obavy o budoucnost tohoto bezpečnostního nástroje, ale volání po začlenění do hlavní řady pravděpodobně nebude úspěšné. Postupem času, zejména díky snaze lidí mimo projekt, se různé části grsecurity (a s ním spojeného projektu PaX) dostaly do jádra, ale z mnoha důvodů kompletní patch v hlavní řadě není; základní důvod je ten, že vývojáři, jak se zdá, nemají zájem nebo nechtějí dodržovat standardní cestu pro začlenění.
Patch grsecurity implementuje mnoho bezpečnostních funkcí, které jsou užitečné obzvláště pro webové servery nebo servery, které nedůvěryhodným uživatelům poskytují přístup k shellu. Jednou z hlavních vlastností je řízení přístupu založené na roli [role-based access control, RBAC], která je alternativou k tradičnímu UNIXovému volnému řízení přístupu [discretionary access control, DAC] nebo novějšímu povinnému řízení přístupu [mandatory access control, MAC] poskytovanému SELinuxem nebo Smack. Cílem RBAC je vytvoření systému s "nejmenšími právy", kde uživatelé a procesy mají jenom nejnutnější práva potřebná k provedení svých úkolů. grsecurity také zahrnuje vytvrzení systémového volání chroot(), aby se eliminovalo povýšení práv a další slabiny "vězení v chrootu" [chroot jail]. Navíc je zde mnoho dalších různých vlastností jako auditování a omezení přístupu k informacím v /proc, všechny vlastnosti jsou vyjmenovány na stránkách grssecurity.
Další důležitou komponentou grsecurity je kód PaX, který omezuje přístup k paměti, takže jsou různé exploity jako přetečení bufferu a další slabiny při vykonávání kódu otupeny nebo eliminovány. Toho se dosahuje tak, že jsou datové stránky nastaveny jako nespustitelné použitím - nebo emulací - bitu "nevykonávat" (NX). PaX omezuje mprotect(), aby nepřipouštěl stránky, které jsou zapisovatelné a zároveň spustitelné, aby se také zabránilo vkládání kódu. Také přidává mnohem agresivnější znáhodňování rozvržení adresového prostoru (ASLR) než to, které nyní Linux používá. PaX je vyvíjen odděleně od grsecurity anonymním "PaX týmem" a začleňován do grsecurity vývojářem Bradem Spenglerem.
Projekt je tu po dlouhou dobu; grsecurity začal v roce 2001, PaX roku 2000. Je mnoho spokojených uživatelů a grsecurity se používá v distribucích jako NetSecL a Hardened Gentoo, ale nikdy se nedostalo do hlavní řady jádra. Gábor Micsko nedávno zaslal Linusu Torvaldsovi žádost na linux-kernel, aby grsecurity znovu zvážil:
Linus odpověděl, že většina toho, co je v grsecurity a PaX je šílený a velmi obtěžující a invazivní kód. Pak pokračoval vylíčením části historie:
Zjevná neschopnost (a co je možná důležitější - naprostá neochota) PaX týmu vidět, co má dlouhodobě smysl v obecném jádře, a co ne, rozdělit věci a ty rozumné tlačit nahoru (a vědět, které věci jsou příliš ošklivé nebo specializované na to, aby dávaly smysl) způsobily, že většina funkcí PaX nikdy nebyla začleněna.
Velká část byla začleněna během let (většinou protože si někdo strávil čas tím, že věci rozdělil), ale ne, nezačneme najednou začleňovat kód jenom proto, že projekt má problémy. Žádný ze základních problémů nebyl vyřešen.
Perfektní příklad neochoty spolupracovat s jadernými hackery je ztělesněn v rozhodnutí neimplementovat RBAC jako linuxový bezpečnostní modul (LSM). Ať už je to dobře, či ne, LSM je mechanismus, který implementuje řízení přístupu v jádře. Koncepčně se hodí k RBAC kódu grsecurity. Možná by byly zapotřebí nějaké LSM háčky navíc, ale zapracování na přidání těchto háčků je správný přístup. O LSM panovala jednu dobu nejistota, ale dnes je to zjevně cesta kupředu.
Dalším problémem kódu PaX by mohlo být to, že není povoleno anonymní přispívání do jádra. Pravděpodobně Brad nebo jiný zaujatý vývojář by mohl tento kód podepsat, ale přímo od "PaX týmu" být přijat nemůže.
V rozsahu, v jakém byly grsecurity a PaX navrhovány k začlenění, byly vždy prezentovány jako jediný monolitický patch. Nikdy nedošlo k pokusu rozdělit patch na logické části, které by bylo možné přijmout nebo odmítnout podle jejich individuálních hodnot. Doteď k tomu nedošlo ani poté, co projekt ztratil sponzora; čekání do poslední chvíle ale nebude fungovat, jak to říká Robert Hancock:
Pokud má existující kód svou hodnotu, zainteresování uživatelé a vývojáři musí pracovat podle obvyklých způsobů, aby byl začleněn. To znamená, že je potřeba identifikovat užitečné kousky a postupovat odtud. Valdis Kletnieks navrhuje:
Opět se jedná o další příklad nebezpečí kódu mimo strom. Podle všech měřítek má grsecurity spokojené uživatele, kteří budou opuštěni, pokud projekt grsecurity nesežene do konce března sponzory. Uživatelé mohou samozřejmě nadále provozovat o grsecurity vylepšená jádra, která v současnosti mají, ale nebudou moci využít pokroky v nadcházejících vydáních jádra.
Zainteresovaní uživatelé se možná shromáždí a budou aktualizovat grsecurity podle nových jader, ale to stále nemění základní problém, že by lépe udělali, kdyby strávili alespoň část svého času tím, že budou spolupracovat s jadernými vývojáři, aby bylo co nejvíc z grsecurity a PaX začleněno do hlavní řady.
Souborový systém Btrfs byl vyvíjen poslední rok nebo tak nějak; po většinu tohoto času byl považován za nejpravděpodobnější "souborový systém nové generace" pro Linux. Nicméně předtím, než bude moci o tento titul usilovat, se Btrfs musí stabilizovat a najít cestu do hlavní řady jádra. Vývojář Btrfs Chris Mason již nějakou dobu říká, že kód se dá dohromady rychleji, pokud bude začleněn relativně brzo, i když ještě není doopravdy připraven na produkční nasazení. Obecná zkušenost s vývojem jádra toto tvrzení podporuje: kód ve stromě je revidován, testován a opravován více než kód mimo strom. Komunita vývojářů tedy v rozumných mezích podporovala relativně brzké začlenění Btrfs.
V poslední epizodě Andrew Morton navrhl, že cílem by mělo být začlenění do 2.6.29. Chris by byl rád, kdyby k tomu došlo, za tímto účel zaslal verzi Btrfs ke zvážení. Není překvapující, že toto zaslání ještě zvýšilo zájem, který byl tomuto kódu věnován; výsledkem bylo, že Chris rychle obdržel seznam věcí, které je potřeba opravit. Většina z nich byla nyní vyřešena, ale zbývá několik záležitostí, které by mohly zabránit začlenění Btrfs v tomto vývojovém cyklu. Tento článek se dívá na potenciální překážky.
Jednou z nich je API pro uživatelský prostor. Btrfs s sebou přináší celou sadu nových ioctl() volání, žádné z nich přitom nebylo významněji revidováno nebo dokonce zdokumentováno. Tato volání provádějí funkce, jako je vytváření snapshotů, zahájení defragmentace, vytváření nebo změny velikosti podsvazků, přidávání zařízení do sady zařízení atd. Zajímavé je, že se neobjevily žádné významné stížnosti na vlastnosti správy svazků v Btrfs obecně. Rozhraní k takovýmto vlastnostem nicméně vyžaduje podrobné prozkoumání; API pro uživatelský prostor normálně nesmí být narušeno poté, co je začleněno do hlavní řady. Padly nějaké návrhy, že by u Btrfs byla učiněna výjimka, protože je velmi malá šance, že by systémy začaly být závislé na specifickém rozhraní předtím, než bude Btrfs připraveno k nasazení.
Nicméně i tak až distribuce začnou dodávat nástroje pro Btrfs - aby pomohly testerům, když nic jiného - způsobí změna API problémy. Jakýkoliv potenciál pro tento druh problémů by značně ztížil změny, Linux by tak mohl skončit s raným API Btrfs. Vzhledem k tomu, že přinejmenším jeden vývojář si myslí, že toto API je nutné významně přepracovat, mohla by se tato záležitost změnit ve významnou překážku.
Pak je zde záležitost zamykacích primitiv pro zvláštní účely, které Btrfs používá. Aby bylo možné této diskuzi porozumět, stojí za to se podívat na zamykací funkci použitou uvnitř Btrfs:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int btrfs_tree_lock(struct extent_buffer *eb)
{
int i;
if (mutex_trylock(&eb->mutex))
return 0;
for (i = 0; i < 512; i++) {
cpu_relax();
if (mutex_trylock(&eb->mutex))
return 0;
}
cpu_relax();
mutex_lock_nested(&eb->mutex, BTRFS_MAX_LEVEL - btrfs_header_level(eb));
return 0;
}
Zámek, o který se jedná, je mutex, ale je získáván poněkud zajímavým způsobem. Jestliže je držen jiným procesem, funkce se ho bez spaní pokusí získat 512krát s nadějí, že bude rychle dostupný. Pokud se tak stane, zámek lze získat úplně beze spaní. Po 512 neúspěšných pokusech se funkce konečně vzdá a uspí se.
Chris toto chování ospravedlňuje takto:
Zdá se, že má cenu jít za takto významným nárůstem výkonnosti. Ve skutečnosti to odráží fenomén, který byl pozorován i v jiných situacích: i když jsou používány spící zámky, výkonnost se často zlepší, když se procesor po nějaký čas opakovaně snaží získat zámek, o který se soupeří, s nadějí, že bude za chvíli k dispozici. Pokud lze zámek získat bez spaní, odpadne režie spojená s uspáním procesu a jeho opětovným probuzením. Kromě toho je zde fakt, že proces, který se snaží získat zámek, je pravděpodobně z větší části nahrán v cache CPU. Umožnit tomuto procesu dál běžet téměř určitě povede k lepšímu výkonu systému, pokud je zámek získán rychle.
Z tohoto důvodu byl minulý rok vyvíjen patch adaptivních zámků v reálném čase, i když si nikdy nenašel cestu do hlavní řady. V reakci na diskuzi o Btrfs Peter Ziljstra navrhl patch točícího se mutexu [spinning mutex patch], který má poskytnout stejné výhody jako zamykací funkce použitá v Btrfs, ale pro všeobecnější použití a bez magických konstant. V Peterově patchi se snaha získat zámek, o který se soupeří, opakuje tak dlouho, dokud proces držící daný zámek skutečně běží na některém CPU. Jakmile se držitel zámku uspí, jakýkoliv proces snažící se získat zámek se také uspí. Heuristika dává smysl, detailní benchmarky však zaslány nebyly. Patch byl přijat vcelku dobře, Linus nicméně trval na některých změnách.
Obecnější točící se mutex tedy může najít svou cestu do hlavní řady, jestli se tam ale dostane v 2.6.29, to není jasné. Vývojáři většinou chtějí, aby jejich vnitřní zamykací primitiva byla rozumně dobře otestována; začlenění něčeho, co bylo vyvinuto těsně před koncem začleňovacího okna, by mohlo být obtížné. Dokud se něco takového nestane, Chris nemá zájem odstranit svou zvláštní zamykací funkci:
Nakonec je tu otázka pojmenování. Někteří revidovatelé navrhli, že by souborový systém měl být začleněn pod jménem, které dává najevo, že není míněn pro produkční nasazení - "btrfsdev" například. Chrisovi se tento nápad nelíbí, poznamenává k němu, že na rozdíl od existujících souborových systémů je Btrfs znám tím, že je nový a nemá žádnou reputaci stability. Prohlásil nicméně, že je ochoten tuto změnu provést, pokud bude opravdu považována za nutnou. Bruce Fields upozornil na to, že nazývat ho "Btrfs" od začátku by mohlo poškodit budoucí vývojáře, kteří nabootují staré jádro (s neprodukční verzí Btrfs) po přepnutí na novou verzi, která je připravena k nasazení.
To všechno pro Btrfs v 2.6.29 znamená nejistý osud; je zde vcelku slušné množství otevřených záležitostí a blíží se konec začleňovacího okna. Je samozřejmě možné začlenit Btrfs po 2.6.29-rc1; vzhledem k tomu, že je to zcela nový subsystém, nezpůsobí regrese, ale jestliže se Linus rozhodne, že je v současném kódu Btrfs příliš mnoho nedotažených záležitostí, může se prostě rozhodnout dát mu další vývojový cyklus před začleněním do hlavní řady. Takže i když nikdo asi nepochybuje o tom, že Btrfs bude začleněn, stále je tu otázka kdy.
(Pokud se usměje štěstí, doufáme, že v některých z následujících Jaderných novin budeme mít rozhodný článek o Btrfs, jakmile ho autor sepíše. Nepřepínejte.)
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
"audio zařízení Palm T|X, T5 a LifeDrive"
to je zase preklad smarja ... to co tam bylo zaclenene je ASoC audio driver pro Palmy (cili velmi zjednodusene specializace driveru pro zvukovy chip na vyse zminenych Palm.* zarizenich - coz jsou kapesni pocitace (tzv. PDA)). Kvalita prekladu zacina pokulhavat 
"audio zařízení Marvell Zylonite" tohle taky ... Zylonite je nakej board, ne zvukovka.
Mne udrela do očí veta "... poskytovanému SELinuxem nebo Smack", kde prvý názov je vyskloňovaný a druhý nie je.SMACK je zkratka. Kdyby se to jmenovalo SMACKLinux, tak bych skloňování chápal.
<abbr title="Simplified Mandatory Access Control Kernel">SMACK</abbr>by v tom prípade bolo asi vhodnejšie
Je možné oponovať argumentom, že samotní autori používajú "Smack". Na to sa da spýtať, kde sa vzala verzia napísaná veľkými písmenami v prvej kapitole týchto JN.A na to se dá odpovědět, že samotný autor v daném místě použil verzi napsanou velkými písmeny. FYI originál JN nepíše jeden člověk, ale dva + nepravidelní přispěvatelé.
Chcem len povedať, že v tak technickom texte ako sú JN musí snaha za každú cenu dodržať pravidlá slovenského/českého jazyka stroskotať.Sám jsi to napsal - Kde je vôľa, tam je cesta.
Možná by bylo užitečné uvést možné řešení. V nějaké překladatelské příručce jsem našel tuto jednoduchou radu. Jestliže potřebuješ vyskloňovat nějakou zkratku nebo cizí slovo bez běžného překladu, předřaď před zkratku české podstatné jméno a to vyskloňuj. Takže můj návrh zní: ... poskytovanému systémem/subsystémem/komponentou/implementací SELinux nebo Smack.
Možná by bylo užitečné uvést možné řešení.Prvá veta.
… místo poradních zámků [advisory locks].Přijde mi, že termín nepovinné zamykání/zámky je výstižnější (a zatím jsem se s jiným překladem nesetkal).
jestli v najdeme nějakou hloupou chybu
V síťové vrstvě jsou nyní podporovány algoritmus omezující TCP zácpu CUBIC 2.3 [TCP congestion control algorithm] a vlastnost "zpětné upozornění na zácpu" [backward congestion notification].Přišlo by mi lepší "...je nyní podporován...", ten přívlastek u algoritmu je dost dlouhý a s tím množným číslem se to špatně čte, člověk pořád hledá, kde už ten přívlastek skončí a bude pokračovat něco dalšího, co je podporováno.
API NAPI bylo trochu pročištěno. konkrétně funkceMá být velké písmeno po tečce.
Všechno zpracování nyní probíhá v kontextu tvrdého IRQ (hardirq)Chybí tečka na konci věty.
Se začleněním těchto háčků byla odstraněna jedna hlavní překážka začlenění bezpečnostních modulů jako AppArmor a TOMOYO.Asi buď "jedna překážka" nebo "jedna z hlavních překážek".
Dvě nové funkce - stop_machine_create() a stop_machine_destroy() - umožňují nezávislé vytváření vláken používané stop_machine()Nemělo by tam být používaných? Nebo to má význam
umožňují funkcí stop_machine() používané nezávislé vytváření vláken?
většinou protože si někdo strávil čas tímPřebývá "si".
Říct jaderným vývojářům "vezměte tenhle velký kus kódu a hoďte ho do svého jádra, protože když to neděláte, tak si sebereme svůj míček a jdeme domů," není způsob, jakým to tu funguje.Neděláte -> neuděláte; čárka před ukončující uvozovkou je podle mne nadbytečná. Asi jsem v poslední době četl nějak hodně textů ke korekturám a zůstalo mi to
Asi jsem v poslední době četl nějak hodně textů ke korekturám a zůstalo mi toNo co, minule sis stěžoval, že nemáš co opravovat, tak jsme ti tam tentokrát nechali nějaké chyby
Jenom co se týče:
Přišlo by mi lepší "...je nyní podporován..."Mě ne.