Jaderné noviny - 11. 2. 2009

9. 3. 2009 | Jirka Bourek | Jaderné noviny | 3236×

Aktuální verze jádra: 2.6.29-rc4. Citáty týdne: Rusty Russell, Andrew Morton. Jak se patche dostávají do hlavní řady. Probouzecí zámky a problém v nich. DazukoFS: skládatelný souborový systém pro vyhledávání virů.

Obsah

• Aktuální verze jádra: 2.6.29-rc4
• Citáty týdne: Rusty Russell, Andrew Morton
• Jak se patche dostávají do hlavní řady
• Probouzecí zámky a problém v nich
• DazukoFS: skládatelný souborový systém pro vyhledávání virů

Aktuální verze jádra: 2.6.29-rc4

Současné vývojové jádro 2.6 je stále 2.6.29-rc4 vydané 8. února. Obsahuje dlouhý seznam během týdne a půl začleněných oprav chyb. Zkrácený changelog je v oznámení, v kompletním changelogu vizte všechny detaily.

Současné stabilní jádro 2.6 je 2.6.28.4 vydané (společně s 2.6.27.15) 6. února. Obě aktualizace obsahují dlouhý seznam oprav. 2.6.28.5 a 2.6.27.16 - obsahující další dlouhý seznam oprav - jsou revidovány v době psaní tohoto článku; s největší pravděpodobností budou vydány 12. února.

Citáty týdne: Rusty Russell, Andrew Morton

Nakonec to vůbec nebyla maska cpu [cpumask]; byl to jenom pozůstatek po používání sigaction v obsluhách přerušení. A v jádře jsme ji nastavovali od roku 1995.

Předpokládám, že se jí nepodařilo přivolat duchy našich předků, takže vytvořím patch, který ji odstraní.

-- Rusty Russell

Pište, prosím, dobré changelogy. Není to jenom zbytečné cvičení v účetnictví. Lidé se rozhodují o tom, které verze patchů jádra mají začlenit a chtějí tedy vědět, jestli konkrétní patch opravuje konkrétní problém, který mají. K tomu potřebují informace.

-- Andrew Morton

Jak se patche dostávají do hlavní řady

Bylo nebylo, dostat patch do jádra znamenalo poslat ho e-mailem Linusu Torvaldsovi. Vývojář potom s nadějí očekával, až Linus vydá nový jaderný strom, a v něm viděl, jestli byl patch zahrnut, nebo ne. V tom druhém případě vytrvalejší vývojáři patch zaslali znovu. A často museli být opravdu vytrvalí, pokud chtěli, aby byl jejich kód opravdu začleněn. Jinými slovy - systém byl ztrátový; nikdy se už nedozvíme, kolik užitečného kódu bylo zahozeno.

Používání gitu (a předtím BitKeeperu) přineslo konec této éry. Jakmile se změna dostane do něčího stromu, je relativně nepravděpodobné, že by se ztratila. Pro všechny zúčastněné je to mnohem lepší způsob, jak pracovat; důležité opravy se již neztrácejí a vývojáři se místo toho, aby museli hledat své patche a zasílat je znovu, mohou věnovat vytváření nových chyb k opravení.

Krom toho se však věci změnily i tak, že pro většinu vývojářů neznamená dostat patch do jádra zaslat ho Linusovi. Místo toho svou práci předají přes strom subsystému. Tento mechanismus je relativně dobře chápán, ale, alespoň pokud autor tohoto článku ví, nikdo se pořádně nepodíval na to, jak vypadá tok patchů do hlavní řady jádra nyní. Proto se Jon Corbet odhodlal ke komplementárním úkolům (1) zmapovat cesty, kterými se patche ubírají na své cestě k Linusovi, a (2) zjistit, jak funguje Graphviz. Na obou frontách bylo dosaženo určitých úspěchů.

V dobách BitKeeperu se Jon zeptal Larryho McVoye, jestli existuje nějaký způsob, jak sledovat, kterými repozitáři prošla specifická sada změn; tuto informaci bohužel BitKeeper nezachovával. Jak se ukázalo, v tomto ohledu odvádí git mnohem lepší práci - i když záznamy také neuchovává perfektně. Když Linus přetáhne [pull] strom od nějakého jiného vývojáře, git (obvykle) přidá do repozitáře "merge commit", který obsahuje informaci, odkud ten strom přišel. Commit má (minimálně) dva rodičovské commity; jeden je ten, který byl na vrcholu Linusova stromu před začleněním, zatímco druhý ukazuje na vrchol proudu sad změn, který přišel z přetaženého stromu. Lze sloučit několik stromů naráz; v takovém případě budou víc než dva rodičovské commity.

Sledováním odkazů na každý commit k jeho rodiči je možné vysledovat, z kterého stromu přišel který commit. Začleňování jsou také šířena přes operace přetažení, takže je možné sledovat tuto historii zpět k libovolnému počtu stromů. Nástroj gitk hezky zobrazuje, jak se různé cesty sešly v jednom repozitáři; výsledný graf může být relativně složitý. Jon vytvořil statistický pohled na tento proces; tento pohled ztrácí informace o specifických patchích, ale poskytuje místo něj přehled o tom, jak se patche dostávají do hlavní řady.

Část výsledného grafu vidíte vpravo; celý graf je poměrně velký, kliknutím na náhled ho zobrazíte celý. Lze připustit, že obrázek je poněkud zmatený, ale některé zajímavé věci z něj vykukují. První je fakt, že graf je poměrně mělký: ukazuje 107 stromů, z nichž téměř všechny přechází přímo do hlavní řady. Co se vývojového cyklu 2.6.29 týče, pouze pár stromů je přetaženo do odděleného stromu subsystému předtím, než jdou k Linusovi, a jenom jeden strom posílá patche přes dvě úrovně. Z větší části správci subsystémů chodí rovnou za Linusem bez jednání s prostředníky.

975 z 11 260 sad změn šlo do hlavní řady přímo bez existence v jakémkoliv subsystémovém stromu. Některé z nich jsou slučovací sady změn, které vytváří Linus, když stromy přetahuje; mnoho ze zbytku jsou patche, které přichází od Andrewa Mortona. Velmi málo jich napsal Linus sám. Příležitostně je také začleněn patch zaslaný přímo od vývojáře, ale to je relativně vzácný jev.

Když tato čísla interpretujeme, je zde jedna věc, kterou je nutné mít na mysli: ve výchozím nastavení git neukládá začleňovací informace, když začleňuje v režimu "rychle vpřed" [fast forward]. Pokud vývojář stáhne celý současný repozitář hlavní řady, přidá na vrchol nějaké patche a poté přiměje Linuse k tomu, aby tyto patche přetáhl předtím, než se v hlavní řadě cokoliv změní, tyto patche lze přidat přímo do hlavní řady bez potřeby začleňovacího commitu, který by držel věci pohromadě. Začleňování rychle vpřed je v hlavní řadě (pravděpodobně) vcelku vzácné, ale na úrovni subsystémů se může dít častěji. Když tedy tyto informace generujeme z gitového repozitáře, nebudou nikdy 100% kompletní; některá začlenění (a repozitáře, odkud přišla), budou neviditelná.

Co se 2.6.29 týče, dva síťovací stromy spravované Davidem Millerem byly největšími přestupními body pro sady změn (pro 1910 z nich), které mířily do hlavní řady; mnoho z nich přišlo z bezdrátového stromu Johna Linvilla. Na druhém místě je strom "linux-2.6-tip" (strom spravovaný Ingo Molnárem a spol., obsahuje několik subsystémů včetně architektury x86 a plánovače), který v tomto vývojovém cyklu přispěl 1270 sadami změn. Mezi další velké zdroje změn patří strom btrfs (910 sad změn - kompletní vývojová historie btrfs), strom Video4Linux, strom zvuku a strom architektury ARM. Na druhém konci škály bylo dvanáct stromů zdrojem pěti nebo méně změn.

Pro zvědavé jsou statistiky k dispozici v textové podobě společně s celými jmény relevantních gitových repozitářů. Kód, který tyto informace vygeneroval, je k dispozici jako část repozitáře gitdm na git://git.lwn.net/gitdm.git. Zjevným možným místem pro vylepšení je sledovat informace o větvích uvnitř repozitářů; to by zvýšilo rozlišení celého obrazu. To ale přijde až v dalším vývojovém cyklu; nepřepínejte.

Probouzecí zámky a problém v nich

Je známo, že vztahy mezi vývojáři embedded systémů a jadernou komunitou jsou přinejlepším napjaté. Vývojáři jádra si stěžují na nekvalitní práci a nedostatek příspěvků ze strany vývojářů pro embedded zařízení; ti si zase, pokud vůbec něco řeknou, stěžují na to, že jaderná komunita nebere v úvahu jejich potřeby. V současnosti probíhající diskuze s vývojáři z projektu Android poskytuje náhled na to, odkud se toto neporozumění bere.

Android je samozřejmě platforma Googlu pro mobilní telefony. Původní Android byl vyvinut za zavřenými dveřmi; kód se dostal ven až poté, co už se vyráběly první série. Vývojáři Androidu udělali spoustu práce na jádře, ale jen velmi málo kódu podniklo cestu do hlavní řady. Kód, když už byl vůbec začleněn, šel všechen do stromu staging bez velké iniciativy na straně Androidu. Nyní se vývojář Androidu Arve Hjønnevåg snaží začlenit část infrastruktury projektu obvyklým procesem. A není to vůbec jednoduché.

Nejkontroverznějším kusem kódu je vlastnost nazvaná jako "probouzecí zámky" [wakelocks]. V jazyku Androidu jsou probouzecí zámky mechanismus, který brání systému přejít do stavu se sníženou spotřebou. Jenom v rychlém pohledu, jádro může nastavit probouzecí zámek nějak takto:

#include <linux/wakelock.h>

wake_lock_init(struct wakelock *lock, int type, const char *name);

Hodnota type popisuje, o jaký druh probouzecích zámků se jedná; name mu přiřazuje jméno, které lze vidět v /proc/wakelocks. Pro typ existují dvě možnosti: WAKE_LOCK_SUSPEND brání systému v uspání, WAKE_LOCK_IDLE brání přechodu do stavu snížené spotřeby, který může zvýšit dobu odezvy. API pro získávání a uvolňování zámků je:

void wake_lock(struct wake_lock *lock);
void wake_lock_timeout(struct wake_lock *lock, long timeout);
void wake_unlock(struct wake_lock *lock);

Také je zde rozhraní pro uživatelský prostor. Zápis jména do /sys/power/wake_lock vytvoří zámek daného jména, které lze následně zapsat do /sys/power/wake_unlock a zámek uvolnit. Současná sada patchů umožňuje převzít zámky pouze z uživatelského prostoru.

Toto zaslání nebylo přijato příliš dobře. Naopak přitáhlo komentáře jako tento od Bena Herrenschmidta:

Zdá se mi, že pár lidí nahackovalo nějaký ad-hoc trik pro své lokální potřeby místo toho, aby přišli na to, jak věci vyřešit s existující infrastrukturou (nebo možná navrhnout takové změny, aby existující infrastruktura řešila jejich potřeby.)

Nebo tento od Pavla Machka:

Ok, řekl bych, že tahle věc s probouzecími zámky je někde v oblasti "nelze rozumně používat" na Rustyho stupnici ošklivosti rozhraní.

Důvody, proč si toto rozhraní neoblíbit, nekončí. Většina z něj duplikuje existující API pm_qos (quality of service, kvalita služby); zdá se, že pm_qos nevyhovuje potřebám Androidu, ale také že nebyla žádná snaha problémy napravit. Zdá se, že schéma je příliš složité, když všechno, co je skutečně potřeba, je příznak "neuspávat" nebo maximálně čítač. Patche vypínají existující rozhraní /sys/power/state, které s probouzecími zámky nefunguje dobře. Neexistuje možnost obnovy, když se proces v uživatelském prostoru ukončí, zatímco drží zámek. Výchozí chování systému je uspávat se, i když běží procesy; udržet systém vzhůru může vyžadovat řetěz probouzecích zámků, které získají různé systémové komponenty. A tak dál.

Konečným výsledkem je, že tento kód se do hlavní řady nedostane. Byl ale dodán ve velkém počtu telefonů G1 a mnohem více se jich chystá. Uživatelé těchto telefonů tedy budou používat kód mimo strom, který nebude začleněn, přinejmenším rozhodně ne v současné podobě. Jakákoliv aplikace, která závisí na sysfs rozhraní probouzecích zámků, přestane fungovat, až se toto rozhraní dostane na standardní úroveň. Je to zmatečné, ale jde o zmatek, který je typický pro vývoj embedded zařízení. Vývojáři těchto zařízení totiž pracují s omezeními, kvůli kterým je dodržování správného postupu vývoje jádra obtížné. Například:

• Jedním ze základních pravidel vývoje jádra je "zasílat brzy a často". Kód, který je vyvíjen za zavřenými dveřmi nemá žádnou zpětnou vazbu od komunity vývojářů, takže snadno může jít dlouho slepou uličkou. Prodejci embedded systémů nicméně většinou nechtějí, aby se svět dozvěděl, co se chystá, dokud produkt není připraven k prodeji; doufají, že jejich konkurence bude tápat ve tmě tak dlouho, jak to jen bude možné. Zasílání brzy tedy většinou není přípustné.

• Další důležité pravidlo je "nejprve do upstreamu": kód se musí do hlavní řady dostat dřív, než je dodán zákazníkovi. I zde i kdyby prodejce chtěl zaslat kód do hlavní řady, výjimečně tak bude chtít učinit předtím, než se produkt začne dodávat. Jádra v embedded zařízeních jsou tedy dodávána s kódem mimo strom, který má téměř jistě řadu problémů, nepodporovatelné API a další.

• Od jaderných vývojářů se očekává, že jejich cílem je vylepšit jádro pro všechny. Vývojáři embedded zařízení na druhou stranu obecně řeší vysoce specifický problém s přísným časovým omezením. Proto nepřemýšlí o tom, že by například rozšířili existující API kvality služby tak, aby splňovalo jejich potřeby; místo toho nabuší něco, co je rychlé, ošklivé a neprochází revizí v upstreamu.

Dalo by se dohadovat, že Google má čas, zdroje a vlastní vědomosti, díky kterým by se všem těmto problémům mohl vyhnout a udělat věci dobře. Místo toho se nám dostalo poměrně klasické ukázky toho, jak se věci mohou pokazit.

Dobrá zpráva je, že vývojáři z Googlu nyní kontaktují komunitu a snaží se dostat svůj kód do hlavní řady. Tento proces může trvat dlouho a vyžadovat hodně změn na straně Androidu. I kdyby návrh probouzecích zámků jako způsobu, kterým zabránit systému uspat se, byl přijat - což není vůbec jisté - rozhraní bude potřebovat značně změnit. S ním spojené API "časného uspání" [early suspend] - což v je v podstatě mechanismus upozorňující na změny stavu systému - bude muset být zobecněno nad specifické potřeby telefonu G1. Snadno to může znamenat spoustu práce.

Když nicméně bude tato práce provedena, jádro bude mnohem lépe vybaveno k tomu řešit potřeby správy napájení přenosných zařízení. Z toho by mohl každý, kdo pracuje na nasazení Linuxu v embedded zařízeních, jenom profitovat. A, což je důležité, pomohlo by to vývojářům Androidu, až budou svůj kód portovat na jiné zařízení s jinými potřebami. Až počet na Androidu založených telefonů vzroste, náklady na údržbu kódu mimo strom, aby podporoval všechna zařízení, budou také růst. Bylo by mnohem lepší tuto podporu zobecnit a dostat do hlavní řady, kde by ji mohla spravovat a vylepšovat komunita.

Zdá se, že většina prodejců embedded systémů nebude chtít tuto práci dělat; mají příliš mnoho práce s tím dát dohromady nový produkt. Tento druh kódu tudíž většinou odumírá mimo hlavní řadu a kvalita embedded Linuxu tím trpí. Tento případ bude možná jiný; Google možná využije své zdroje k tomu, aby svůj specializovaný kód dostal do formy a začlenil ho do hlavní řady. Tato snaha by mohla pomoci získat Androidu pověst pevné, dobře podporované platformy pro mobilní využití, což by mělo být dobré pro obchod. Autor tohoto článku, věčný optimista, doufá, že se věci odehrají takto; byla by to dobrá demonstrace toho, jak komunita vývojářů embedded zařízení může lépe pracovat s lidmi od jádra a obratem získat lepší jádro.

DazukoFS: skládatelný souborový systém pro vyhledávání virů

Mimo jádro dlouho existující vlastnost - kterou používá půl tuctu či více antivirových programů - Dazuko nedávno změnila svůj modus operandi ve snaze o začlenění do jádra. Dazuko a nyní DazukoFS jsou mechanismy pro řízení přístupu k souborům, které jsou obecně používány k tomu, aby se viry pro Windows nešířily na linuxové servery. Cíl je v mnoha ohledech podobný fsnotify/fanotify/TALPA, ale DazukoFS je implementován jako skládatelný [stackable] souborový systém se zcela jiným přístupem.

Projekt Dazuko začal téměř přesně před sedmi lety jako snaha umožnit programům v uživatelském prostoru - většinou antivirovým programům ve stylu těch pro Windows - rozhodovat o přístupu k souborům. Jedním důvodem, proč mít vyhledávání virů v uživatelském prostoru - kromě nulové pravděpodobnosti, že by se nějaké dostalo do jádra - je zachovat neutralitu vůči výrobcům nezvýhodňováním žádného konkrétního protivirového enginu. Prostředkem k tomuto cíli se nicméně staly háčky v systémových voláních, což je technika, která se jaderným vývojářům nelíbí. Dazuko ustoupilo k LSM API, ale narazilo na různé problémy, včetně nemožnosti skládat několik bezpečnostních modulů. Nakonec se projekt začal poohlížet po skládatelném souborovém systému jako řešení, které by bylo stravitelné pro přesun do hlavní řady.

Skládatelný souborový systém, který Dazuku poprvé doporučil Christoph Hellwig roku 2004, má nad jinými řešeními mnoho výhod. Jde o samostatné řešení, které nebude vyžadovat žádné změny vnitřních částí jádra [core kernel], pokud si vývojáři antivirů budou přát přidat nové vlastnosti. Také by to znamenalo přidání dalšího skládatelného souborového systému do jádra, což by mohlo pomoci pečovat o obecnější framework skládatelných souborových systémů. Hlavním důvodem je ale to, že projekt tuto cestu vidí jako nejpravděpodobnější pro začlenění. Hlavní vývojář John Ogness vysvětluje:

Téměř sedm let vývoje mimo strom bylo více než dost na to, aby se ukázalo, že ovladače mimo strom mají zbytečně velké udržovací náklady (které se zvyšují s každou novou verzí jádra). S DazukoFS v hlavní řadě by výrobci antivirů konečně měli oficiální rozhraní a implementaci, na které by mohli založit své v reálném čase prohledávající aplikace.

Aby mohl řešit rozhodnutí o přístupu k souborům, je DazukoFS připojen do již připojeného souborového systému. Například:

mount -t dazukofs /opt /opt

nastaví souborový systém /opt pro kontrolu procesů v uživatelském prostoru, které otevřou speciální soubor v /dev. Veškeré interakce mezi prohledávacími aplikacemi a DazukoFS se odehrávají přes /dev soubory, všechno je zdokumentováno v Documentation/filesystems/dazukofs.txt.

Rozhodování o přístupu k souborům přísluší procesům nebo vláknům, které tvoří "skupinu". Skupina se chová jako fond [pool] dostupných prohledávačů, které umožňují několik paralelních rozhodování o přístupu k souborům. Jakmile je fond zcela zaneprázdněn, přístupy k souborům blokují, dokud některý z prohledávačů nebude k dispozici. Skupiny se registrují zápisem add=NázevSkupiny do /dev/dazukofs.ctrl. Poté je přiřazeno id skupiny, které lze hledat ve výstupu čtení ze souboru dazukofs.ctrl. ID skupiny se používají k přístupu ke správnému zařízení při rozhodování o povolení přístupu.

V závislosti na id skupiny (N) je vytvořen soubor /dev/dazukofs.N. Každý proces ve skupině se registruje tím, že tento soubor zařízení otevře. Pak by měl blokujícím způsobem číst tento soubor a čekat na událost přístupu k uživatelskému souboru. Každá událost obsahuje tři informace, které se načtou: id události, id programu, který ji vyvolal, a číslo otevřeného popisovače souboru, který lze použít pro čtení obsahu daného souboru. Prohledávající proces by poté měl provést všechno, co potřebuje k rozhodnutí o povolení přístupu.

Protože je mu popisovač souboru předán, nepotřebuje prohledávající proces žádná zvláštní oprávnění kromě přístupu k souborům /dev/dazukofs*. Jakmile je rozhodnuto, proces zapíše řetězec určující výsledek zpět do zařízení. Pak je zodpovědný za uzavření popisovače souboru, který prohledával.

Pomocí API pro uživatelský prostor lze udělat několik dalších věcí: mazat skupiny, poskytnout nějakou ochranu proti pádu uvnitř skupin a řešení přístupů k chráněným souborům z DazukoFS, vše je popsáno v souboru v Documentation.

V tomto vydání DazukoFS je také důležitý problém:

DazukoFS nepodporuje zápis do paměťově mapovaných souborů. Nemělo by to způsobit pád jádra, ale aplikaci se nezdaří do souboru zapisovat (přestože mmap() se bude z pohledu aplikace tvářit úspěšně!)

Z části se to dělá kvůli tomu, aby nemohlo dojít k souběhu, kdy škodlivý program přepíše obsah souboru mezi jeho prohledáním a skutečným přístupem. To je obecně achillova pata mechanismů prohledávání souborů, ale tiché ignorování zápisů do paměťově mapovaných souborů je poněkud extrémní reakce na tento problém. TALPA, ze kterého se nedávno stalo fanotify, definuje tento problém tak, že není součástí modelu ohrožení, na který reaguje. DazukoFS by možná mohlo udělat něco podobného.

Zdálo by se, že jenom jedno z těchto dvou navržených řešení pro hledání virů z uživatelského prostoru skončí v hlavní řadě. John ve svém zaslání patche fanotify zmiňuje:

Jsem si vědom současné práce Erica Parise, ve které implementuje mechanismus pro řízení přístupu ve sjednoceném frameworku inotify/dnotify. I když bych uvítal jakékoliv oficiální rozhraní pro tento mechanismus pro aplikace v uživatelském prostoru v Linuxu, mám pocit, že DazukoFS poskytuje elegantnější řešení. (Všimněte si, že tyto dva projekty vzájemně nejsou v konfliktu.)

Doteď nebylo nijak komentováno zaslání druhé verze patche, ale k prvnímu zaslání v prosinci byly nějaké připomínky. Lidé od jádra jsou obecně dost zaměstnaní, ale v současnosti je navíc revidováno mnoho souborových systémů: btrfs, POHMELFS, DST, FS-Cache a další. Ty pravděpodobně spotřebovávají všechnu dostupnou revidovací sílu. John nedávno oznámil, že končí s podporou Dazuko verze 2.x - založené na háčcích v systémových voláních - aby se mohl zaměřit na DazukoFS. V tomto oznámení upozorňuje na nedostatek revizí:

Jak pravděpodobně víte, DazukoFS bylo navrženo pro začlenění do hlavní řady jádra Linuxu. Bohužel se mu nedostává téměř žádné pozornosti. Nevím, jestli je ticho, protože jsem neposlal kopii správným lidem, protože se na to lidé nechtějí dívat nebo proto, že nikdo z nich na to nemá čas.

Z oznámení je jasné, že John má trpělivost potřebnou k tomu, aby provedl DazukoFS procesem začleňování do jádra. Zdá se, že by také mohlo být užitečné věnovat nějaký čas spoluprací s Ericem Parisem a pokusit se najít společné základy jejich dvou řešení.

       

Komentáře

[hotovson]

Diky za preklady, je to vzdy zajimave cteni. Jen bych upozornil, ze pro slovo stackable je vhodnejsi stohovatelny, ve smyslu vrsit jeden na druhy, nez slovo skladatelny, coz spise evokuje skladani vice dilu do jednoho celku. Myslim, ze se tak prekladaji i stohovatelne prepinace, takze je to zavedeny pojem...

[Jiří J.]

Já bych zase jen rád upozornil, že git-merge má parametr --no-ff, který právě vynutí recursive merge místo fast-forward a vytvoří merge commit, tudíž není podmínkou, že se něco v hlavní řadě musí změnit.

[trekker.dk]

Já bych zase jen rád upozornil, že git-merge má parametr --no-ff, který právě vynutí recursive merge místo fast-forward a vytvoří merge commit, tudíž není podmínkou, že se něco v hlavní řadě musí změnit.

Já bych řekl, že to je z textu poměrně jasné. Teda ne přesně to, že ten parametr je --no-ff, ale že nějaký takový parametr existuje.

[Jiří J.]

Mě to vyžnělo právě naopak
Neviním překladatele ani autora, jen jsem přidal dodatek, jak by toho šlo docílit.

[jik]

Perlička: "... a vývojáři se místo toho, aby museli hledat své patche a zasílat je znovu, mohou věnovat vytváření nových chyb k opravení." Ono je to vlastně pravda

[aR]

Jj, taky jsem si toho hned všiml