Portál AbcLinuxu, 24. dubna 2024 11:44
Jaderné noviny – 16. 12. 2009
Články
-
Jaderné noviny – 16. 12. 2009
Aktuální verze jádra: 2.6.32.1. Citáty týdne: Dave Airlie, Zachary Amsden, Linus Torvalds. Chyby RCU. Omezování spotřeby. kmsg_dumper – informace o pádu systému. Nová sada operací specifických pro CPU. Začleňovací okno 2.6.33, část druhá. Změna návrhu asynchronního uspávání/probouzení. Náhlé začlenění Nouveau.
Obsah
Aktuální verze jádra: 2.6.32.1
link
Začleňovací okno 2.6.33 je stále otevřené, takže v době psaní tohoto článku nebylo vydáno žádné jádro. Vydání 2.6.33-rc1 uzavírající toto začleňovací okno lze očekávat každou chvíli.
Stabilní aktualizace jádra: 2.6.32.1 a 2.6.31.8 byly vydány 14. prosince. Obě obsahují dlouhý seznam oprav, mnoho z nich patří k souborovému systému ext4.
Citáty týdne: Dave Airlie, Zachary Amsden, Linus Torvalds
link
Ne mami, to jenom tvůrce Linuxu mi v pátek odpoledne naložil další práci. Táta o tom určitě najde nějaký článek.
-- Dave Airlie
K čertu, to jsou komplikované hovadiny. Analogická úloha by ve skutečném životě byla nutit tlupu vřešťanů, každého na vlastním stromě, zpívat unisono, zatímco hlavní zpěvák skáče ze stromu na strom, přičemž neviditelný dirigent neustále mění tempo, ve kterém se hraje. Naštěstí tu nejsou žádné změny tóniny, nicméně občas se objeví nový strom nebo starý padne k zemi.
-- Zachary Amsden (díky Markusu Armbrusterovi)
Přesložitělé návrhy jsou HŘÍCH. Je to archetypální příklad toho, čemu říkám „špatný vkus“. Opravdu mě naštve, když správce subsystému začne vymýšlet zbytečné složitosti.
-- Linus Torvalds
Chyby RCU
link
Thomas Gleixner se rozhodl, že zlikviduje ošklivý rwzámek [rwlock] tasklist_lock; v mnoha případech je řešením místo něj použít čtení-kopírování-zápis [read-copy-update, RCU]. Během toho nalezl několik problémů s tím, jak některý kód RCU používá. Tyto problémy si zasluhují krátkou zmínku, protože se mohou objevit i jinde a odrážet zastaralý náhled na to, jak RCU funguje.
Hlavní nápad RCU je zpozdit uvolnění neplatných globálně viditelných dat, dokud není jisté, že je již nikdo nepoužívá. Toho bylo tradičně dosahováno tak, že (1) veškeré přístupy k datům chráněným RCU byly v atomickém kódu a (2) stará data se uvolňovala až poté, co na všech procesorech proběhlo plánování alespoň jednou od doby, kdy byla data nahrazena aktuální kopií. Vzhledem k tomu, že atomický kód nelze přerušit plánováním, je tato sada pravidel dostatečná k tomu, aby bylo jisté, že již neexistují odkazy na stará data.
Není třeba říkat, že kód pracující s daty chráněnými RCU musí běžet se zakázanou preempcí – jinak by se na procesoru mohlo plánovat i v době, kdy na tato data existuje nějaký odkaz. Primitivum rcu_read_lock() proto tradičně preempci zakazovalo. Podle kódu, který Thomas našel, to vedlo k úsudku, že pro kód používající RCU je zakázání preempce dostatečné.
Problém je v tom, že novější formy RCU používají ke sledování chráněných dat sofistikovanější dávkovací mechanismus. Tato změna byla nutná, aby RCU lépe škálovalo obzvláště v situacích (například běh v reálném čase), kde je zákaz preempce nežádoucí. Při používání hierarchického (či „stromového“) RCU bude kód, který jednoduše před přístupem k chráněným datům zakáže preempci, obsahovat ošklivé souběhy. Je tedy důležité při práci s takovými daty použít rcu_read_lock(). Toto pravidlo je bohužel obtížné vynutit automaticky, takže si ho programátoři prostě budou muset zapamatovat.
Omezování spotřeby
link
Salman Qazi mluví o hypotetické situaci, ve které se možná nachází mnoho z nás:
Představte si, že jste v Údolí smrti s laptopem. Nudíte se a chcete si pustit film. Také ale chcete, aby baterie vydržela tak, abyste z filmu viděli co nejvíce.
Navrhované řešení shodou okolností funguje také pro jinou situaci. Představte si, že jste Google a chcete z každého datového centra dostat co nejvíce. Jedním způsobem, jak to udělat, je na dané místo navézt víc strojů, než může dostupné napájení zvládnout, a následně řídit spotřebu jednotlivých strojů tak, aby celková spotřeba zůstala pod limitem.
Konkrétně kód, který Google má, pracuje tak, že vynutí přepnutí procesoru do klidového stavu na určité procento času, přičemž dané procento je nastaveno dynamicky v závislosti na zátěži stroje a datovém centru jako celku. Pokud je zapotřebí, úloha běžící v reálném čase může procesor zabrat a na požadovanou dobu ho nechat v klidu, aby se celkový výpočetní čas vešel do limitu. Objevuje se zde zajímavá heuristika, která se snaží vnutit čekací cykly procesům o nízké prioritě a která zjišťuje, komu byly nečinné cykly naúčtovány.
Tato práce zní podobně jako ACPI ovladač pro zabrání procesoru, který byl přes námitky správce plánovače Petera Zijlstry začleněn do 2.6.32. Peter se k nyní navrhovanému patchi ještě nevyjádřil, ale podle popisu to vypadá jako něco, co se více blíží tomu, co pro tuto funkcionalitu požadoval. Je nicméně těžké to říct s jistotou; kód sám ještě zaslán nebyl. Doufejme, že bude brzy následovat a tuto změnu bude možné skutečně posoudit.
link
Bez ohledu na nové sledovací nástroje většinou jaderní vývojáři sahají po printk() (když se snaží vyřešit problémy). Člověk ale nemusí na jaderném kódu pracovat dlouho na to, aby narazil na nepříjemný fakt: Většina nejzajímavějších výpisů je často vypsána těsně před pádem, ale u mnoha druhů problémů může smrt systému zabránit vypsání těchto kriticky důležitých řádek. Není nijak zábavné zírat na zaseknutý systém a vědět, že informace potřebné pro dohledání problémů pravděpodobně uvízly v nějakém bufferu v paměti.
2.6.33 bude obsahovat nový mechanismus navržený k tomu, aby tyto poslední kousky informací vyrval ze spárů umírajícího systému. Vývojář musí pouze nastavit nový „vypisovač kmsg“ [kmsg dumper]:
#include <linux/kmsg_dump.h>
struct kmsg_dumper {
void (*dump)(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason,
const char *s1, unsigned long l1,
const char *s2, unsigned long l2);
struct list_head list;
int registered;
};
Funkce dump() bude zavolána v případě pádu; dva argumenty s1 a s2 budou obsahovat ukazatele na data ve výstupním bufferu jádra. Dva ukazatele jsou potřeba kvůli kruhové povaze tohoto bufferu; s1 bude ukazovat na starší sadu zpráv.
Registrace a odregistrování těchto funkcí je záležitostí volání:
int kmsg_dump_register(struct kmsg_dumper *dumper);
int kmsg_dump_unregister(struct kmsg_dumper *dumper);
V jádře 2.6.33 byl přepracován modul „mtdoops“ tak, že tento nový mechanismus používá k zapsání dat z pádu na flash zařízení.
Nová sada operací specifických pro CPU
link
Proměnné specifické pro CPU se používají jako technika vylepšující výkonnost. Umožňují procesorům pracovat s daty bez nutnosti zabývat se zamykáním nebo soupeřením o cache. Člověk by chtěl, aby tyto operace byly dobře optimalizovány, ale jak se ukazuje, lze je vylepšit; Tejun Heo a Christoph Lamerter to udělali v 2.6.33 a přitom změnili způsob, jakým mohou vývojáři s těmito proměnnými pracovat.
Je zde sada nových operací:
this_cpu_read(scalar);
this_cpu_write(scalar, value);
this_cpu_add(scalar, value);
this_cpu_sub(scalar, value);
this_cpu_inc(scalar);
this_cpu_dec(scalar);
this_cpu_and(scalar, value);
this_cpu_or(scalar, value);
this_cpu_xor(scalar, value);
Ve všech případech je scalar buď proměnná specifická pro CPU získaná od nového alokátoru, nebo statická proměnná specifická pro CPU získaná z per_cpu_var(). Všechny funkce jsou atomické v tom, že operace nebude na současném procesoru přerušena v půli. Po jejich použití není nutné volat put_cpu().
Příklad toho, jak se operace s proměnnými specifickými pro CPU v novém schématu mění, vizte například na konverzi statistik VM
Začleňovací okno 2.6.33, část druhá
link
Od shrnutí z minulého týdne bylo do vývojového cyklu 2.6.33 začleněno přes 4200 patchů. V době psaní tohoto článku je celkový součet 8152 patchů.
Mezi změny viditelné pro uživatele patří:
Jestli ještě někdo používá ReiserFS: tento souborový systém se dočkal významného přepracování interního zamykání kvůli eliminaci velkého jaderného zámku [Big Kernel Lock]
Architektura Super-H získala podporu pro události výkonnosti [perf events] pro mnoho typů systému.
Souborový systém exofs (pro zařízení ukládající objekty) nyní obsahuje podporu pro zrcadlení více zařízení.
Pro souborový systém ext4 je zde nová připojovací volba „discard“, která řídí, jestli ext4 pro nově uvolněný prostor vysílá příkazy TRIM. Vzhledem k obavám z toho, jak tato vlastnost bude fungovat, až ji hardware začne podporovat, je výchozí hodnota „vypnuto“.
Nyní je možné nakonfigurovat jádro bez podpory ext2 a ext3, ale i tak lze tyto souborové systémy připojit pomocí kódu pro ext4.
Ovladač Nouveau získaný reverzním inženýrstvím z ovladače NVIDIA byl začleněn, ale bez firmwaru, který k němu patří; více informací vizte v tomto článku.
Do stromu staging bylo začleněno zařízení „ramzswap“ dříve známé jako compcache.
Strom staging nyní obsahuje pro mesh síťový protokol „BATMAN“
Nástroj „perf“ má nyní režim „diff“, který vypočítá změnu výkonnosti mezi dvěma běhy a vygeneruje zprávu.
Sémantika příznaků při otevírání souboru O_SYNC a O_DSYNC byla racionalizována tak, jak bylo popsáno v tomto článku.
MD vrstva nyní podporuje požadavky na bariéry pro všechny typy RAID. Podporu bariér vylepšil také device mapper.
Cíl slučování snímků device mapperu byl začleněn.
Do souborového systému XFS byla přidána rozsáhlá sada sledovacích bodů, která umožňuje jemný náhled na většinu jeho práce.
Stránky v paměti sdílené pomocí mechanismu jádrem sdílené paměti [Kernel Shared Memory, KSM] lze nyní odswapovat.
Změny viditelné pro vývojáře jádra:
Zpětné volání detect() ve struktuře struct i2c_driver ztratilo nepoužívaný parametr kind. struct i2c_client_address_data již není mezi námi; seznamy adres jsou místo toho reprezentovány jednoduchými poli unsigned short.
Patch přejmenovávající spinlocky byl začleněn. Vývojáři pracující blízko nízkoúrovňového kódu uvidí u nespících (a to ani v realtime stromě) zámků typ arch_spin_lock_t.
Video4Linux2 má nové API pro podzařízení nazvané media-bus [sběrnice médií], které má pomoci při vyjednávání o formátu obrazu mezi senzorem a řadičem.
Toto začleňovací okno by se mělo ve velmi blízké budoucnosti uzavřít, takže jádro 2.6.33 je nyní, co se vlastností týče, téměř kompletní. Poslední přírůstky z následujícího týdne budou zmíněny v příštích Jaderných novinách.
Změna návrhu asynchronního uspávání/probouzení
link
Kdyby někdo udělal v komunitě uživatelů Linuxu anketu, jenom málokdo by tvrdil, že se mu nelíbí myšlenka na to, že by se jeho systém uspával a probouzel rychleji. Rafael Wysocki na tom pracuje již nějakou dobu; jeho patche pro asynchronní uspávání/probouzení zde byly popsány v srpnu. Tento kód již nějakou dobu nenarazil na žádné turbulence, takže se dalo předpokládat, že Rafaelův požadavek na přetažení do 2.6.33 nebude kontroverzní. Takové předpoklady nicméně zapomněly vzít v potaz jev nazvaný „Linus na poslední chvíli“.
Zde hraje roli jeden důležitý fakt, že jako nikdo jiný ani Linus nemůže sledovat všechny projekty, na kterých se právě pracuje; z toho důvodu je klidně možné, že práce na nějakém projektu dojde ke svému závěru, aniž by si toho jedinkrát všiml. Tento stav nicméně nevyhnutelně končí s tím, že někdo zašle požadavek na přetažení této práce. Je jasné, že některé požadavky jsou zkoumány pečlivěji než jiné, ale na některé se hledí opravdu zblízka. Jak se ukázalo, mezi ty poslední patří i požadavky u správy napájení.
Přinejmenším lze říci, že se Linusovi nelíbilo to, co viděl.
Kód je podle něj zbytečně složitý a možná nebezpečný; odmítl ho přetáhnout. Konkrétně se mu zdálo, že bylo až příliš mnoho práce věnováno tomu namapovat topologii stromu zařízení a všech závislostí mezi nimi. V minulosti pokusy udělat něco asynchronně pouze podle zjevné topologie narazily na potíže; proč by to tentokrát mělo být jinak?
Linus dále navrhl alternativní řešení založené hlavně na stromu zařízení. Přitom chtěl, aby bylo možné, aby většina ovladačů mohla koncept asynchronního uspávání a probouzení úplně ignorovat. Pro většinu hardwaru v systému je čas potřebný pro tyto operace tak krátký, že opravdu nemá cenu dělat to paralelně. Jestliže je možné zařízení uspat během pár milisekund, klidně se to může udělat sériově a vyhnout se přitom složitostem.
Co se zbytku týče, Linus velmi stál o rozhodnutí, jestli se o tom, zda se bude uspávání/probouzení provádět asynchronně, bude rozhodovat na úrovni ovladačů. Jádro správy napájení ale i tak bude potřebovat vědět dost o asynchronním zpracování, aby čekalo na jeho dokončení; nelze uspat řadič, dokud se zařízení k němu připojená také neuspí. Po několika revizích se z Linusova plánu stalo něco takovéhoto:
S každým uzlem ve stromu zařízení je spojen semafor čtenář/zapisovatel (rwsem). Tyto semafory umožňují neomezené množství současných čtecích zámků, ale v daný okamžik může existovat pouze jeden zámek pro zapisovatele a zapisovatelé musí počkat, než čtenáři dokončí svou práci. Na začátku procesu uspávání není zabrán žádný zámek.
Proces uspávání zahájí všichni potomci daného uzlu. Pokud to dělají synchronně, udělá se to hned a není zapotřebí žádná další akce.
Pokud se ovladač rozhodne pro asynchronní uspávání, spustí vlákno, které tuto práci provede. Také zabere čtecí zámek rwsem rodiče.
Když se asynchronní uspání specifického zařízení dokončí, zámek je uvolněn.
Rodičovský uzel získá zámek pro zapisování na svém vlastním rwsem před uspáváním zařízení. Pokud se nějaký potomek uspává asynchronně, zámek bude blokovat kvůli aktivním čtecím zámkům. Teprve když jsou všechny zámky pro čtení uvolněny – tj. všichni potomci se uspali – získá rodič svůj zapisovací zámek a může se uspat.
Při probouzení je nejprve získán zámek pro zapisování a všichni potomci zabírají zámky pro čtení svého rodiče před probouzením hardwaru. Tím se zajistí, že se všechna zařízení probudí předtím, než se začnou probouzet jejich potomci.
Výhodou tohoto schématu je jednoduchost. Jeho implementace nicméně zabrala několik kol diskuzí, ve kterých Linus opakovaně žádal vývojáře, aby tuto jednoduchost zachovali a nepokoušeli se vymýšlet nová schémata pro zamykání. I tak se věci trochu změnily; v době psaní tohoto článku současná sada patchů pro uspávání/probouzení nepoužívá Linusův původní plán. Rafael, který implementoval řešení založené na rwsem, mezi jinými věcmi narazil na problémy s lockdep a s Linusem se shodli, že byly závažné.
Místo toho byla implementována varianta tohoto schématu založená na dokončeních [completions]. Každý uzel zařízení dostane strukturu dokončení, která je zpočátku nastavena do stavu „není dokončen“. Každý ovladač, který implementuje asynchronní uspávání/probouzení, musí zavolat device_enable_async_suspend(), kterou o tom informuje jádro správy napájení. Na tomto jádře nyní je, aby vytvořilo vlákna pro asynchronní operace uspání/probouzení a zavolalo zpětná volání [callback] ovladačů z těchto vláken. Před uspáním specifického uzlu zařízení se bude čekat na dokončení všech potomků, které mají asynchronní zpětná volání. To opět zajišťuje, že jsou všichni potomci uspáni, předtím než se rodičovský uzel uspí sám.
Linusovi se přístup založený na dokončeních nelíbí, ale naznačil, že bude ochoten ho přijmout. V době psaní tohoto článku se tak nicméně nestalo.
Z jedné strany to může být bráno jako nebraní ohledů na čas vývojáře, což je občas během vývojového procesu jádra k vidění. Není zcela neobvyklé, že kód, na kterém se hodně pracovalo, je nakonec zahozen nebo výrazně přepracován. Tento model se může zdát jako plýtvání a je nepochybné, že je pro dotčené vývojáře značně frustrující. Je to ale základní součástí toho, jak funguje řízení kvality v jádře. Tímto přepracováním v poslední minutě byl kód pro uspávání/probouzení zjevně vylepšen. Dalo by se říci, že by bylo lepší, kdyby se tak stalo před několika měsíci, ale pro uživatele Linuxu je nejdůležitější, že se tak vůbec stalo.
Náhlé začlenění Nouveau
link
Začleňovací okno je pro správce subsystémů běžně poměrně hektický čas. Mají dva týdny na to, aby dali dohromady dobře zformovaný strom obsahující všechny změny určené do příštího vývojového cyklu jádra. Příležitostně se ale mohou na poslední chvíli objevit háčky, kvůli kterým je začleňovací okno ještě rušnější než obvykle. Neočekávané začlenění ovladače Nouveau je výsledkem jednoho takového háčku – ale je to příběh se šťastným koncem pro všechny.
Dave Airlie si pravděpodobně myslel, že toho má na talíři už dost, když vygeneroval požadavek na přetažení DRM do 2.6.33. Tento strom obsahoval 203 commitů, které se dotýkaly 122 různých souborů a přidávaly přes 9 000 řádků kódu. Jednou z klíčových vlastností, které se mají dostat do tohoto jádra, je nové „ioctl() pro prohazování stránek“, které je užitečně popsáno ve zprávě u commitu tak, že toto ioctl() vezme ID fb a ID ctrc a prohodí ctrc do daného fb při příštím vblank. V češtině to znamená, že specifický video výstup lze rychle přepnout z jedné oblasti videopaměti do jiné, což umožňuje čisté změny obrazu bez „tearingu“, který je důsledkem zobrazování videobufferu, jež se právě mění.
Další změny DRM tentokrát zahrnují podporu pro GPU Intel „Ironlake“ a procesoru Atom „Pineview“ a spoustu práce podporující jaderné nastavování režimu GPU Radeon. Radeon podle všeho v tuto chvíli postrádá pouze dobrou správu napájení; pravděpodobně před koncem tohoto vývojového cyklu ztratí své označení „staging“.
Linus tímto faktem nebyl nijak ohromen. Místo toho měl připomínku: Fakt, že ovladač Nouveau – reverzním inženýrstvím získaný ovladač pro čipové sady NVIDIA – nebyl součástí požadavku na přetažení. Nouvaeu byl diskutován na Jaderném Summitu 2009 a obecně všichni souhlasili s tím, že by si tento kód měl co nejrychleji najít cestu do hlavní řady. 2.6.33 je první začleňovací okno od summitu a Linus zjevně očekával na této frontě nějakou akci. A když se jí nedočkal, své zklamání dal najevo.
Možná by se někdo mohl divit tomu, co je u Nouveau za problém. Svět je plný ovladačů pro Linux, které jsou mimo strom; nedávné snahy jejich počet významně snížily, ale stále existují a Linus si na ně normálně nestěžuje. Nouveau je rozhodně víc na očích než většina ostatních ovladačů mimo strom; pro velké procento dostupných strojů je to jediná naděje na svobodný ovladač. Skutečný problém je ale to, že Fedora (přinejmenším) tento ovladač dodává, aniž by (podle Linuse) dělala dost pro to, aby se dostal do upstreamu. Linusova slova:
Mám vztek na lidi od distribucí. Už léta distribuce mluví o „nejprve do upstreamu“ kvůli tomu, jaká pohroma byl kvůli fragmentaci Linux-2.4. A většina z nich to také tak dělá a dělá to poměrně dobře.
Ale nejenom že Fedora nedodržuje pravidla, ale vím, že lidé od Fedory si aktivně vymýšlejí výmluvy, proč nedodržují pravidla. Vím, že Red Hat zaměstnává (nemám tušení jestli na plný nebo částečný úvazek) vývojáře Nouveau, a z tohoto důvodu by se Red Hat měl pochlapit a říct, že „začlenění do upstreamu“ je pro ně priorita.
Zaznělo mnoho důvodů, proč Nouveau ještě nebylo začleněno, v rozsahu od „ještě není připraveno“ a „nestabilní API pro uživatelský prostor“ po „ještě jsme si nenašli čas“. Skutečná překážka však v nedávné době byl binární blob, který je ovladačem nahráván do některých GPU NVIDIA. Tento kus kódu známý jako „voodoo“ nebo „ctxprogs“ byl získán pozorováním proprietárních ovladačů při práci. Vzhledem k tomu, že nikdo od projektu Nouveau tento kód nenapsal, nikdo se pod něj také nechce podepsat; není jasné, jestli ho je možné legálně distribuovat. Linuse neobměkčil ani tento důvod, ale fakt jako takový zůstává: Vývojáři berou řádek Podepsáno kým: (Signed-off-by:) vážně a nehodlají ho připojit k něčemu, co by mohlo být právně napadnutelné.
Zjevné řešení, takové, které bylo aplikováno mnohokrát předtím, je vytáhnout firmware z ovladače a nahrát ho do jádra za běhu. A to se přesně u Nouveau stalo: Ben Skeggs věnoval spoustu práce tomu, že ctxprogs odstranil a použil API pro nahrávání firmwaru k nahrání firmware při zavádění ovladače. Dave poté sestavil strom s poníkem DRM Nouveau a požádal o jeho přetažení do 2.6.33. A Linus přesně to udělal.
Potenciální uživatelé budou muset i tak získat „ctxprogs“ odjinud. Z kdovíjakého důvodu jsou ukazatele na „odjinud“ těžko k nalezení, ale autor článku shodou okolností ví, že firmware lze nalézt v gitovém stromě Nouveau. Mělo by postačovat jednoduše popadnout správnou verzi a umístit ji do lokálního adresáře s firmwarem.
To vše naznačuje u Nouveau významný pokrok, ale závislost na firmwaru pochybného původu bude brzdit přijetí ovladače v dlouhodobém měřítku. Proto bylo dobré dozvědět se (z komentáře na LWN), že obsah blobu ctxprogs není tak neprůhledný, jak si mnoho z nás myslelo:
Dnes toho o ctxprogs víme hodně včetně toho, k čemu slouží [přepínání kontextu], co dělají [ukládání/nahrávání stavu PGRAPH] a většiny jejich operačních kódů. Stále je několik neznámých, které nám v současnosti brání sepsat ctxprogs od počátku, ale pracujeme na tom a bude to vyřešeno správně. Což znamená zahození progs od nvidie a sepsání našeho vlastního generátoru.
Zdá se, že se věci pohybují rychle i na této frontě; 15. prosince Ben oznámil dostupnost náhradního firmwaru pro hardware NVIDIA GeForce 6/7. Jde o první verzi tohoto kódu; hrdinní testeři určitě narazí na nějaké problémy. Ale zdá se, že alespoň pro tuto variantu hardwaru byly ty největší problémy překonány. Se štěstím nebude firmware od nvidie zanedlouho zapotřebí. V dlouhodobém měřítku by dokonce mohlo být možné naprogramovat do hardwaru zajímavé možnosti a tím překvapujícími způsoby rozšířit jeho schopnosti.
Bylo nebylo, uživatelé Linuxu si museli dávat velký pozor na to, jaký hardware si koupí. Během let většina těchto problémů vymizela; nyní je jednoduché najít systém, jehož hardware je plně podporován svobodným softwarem. Jedna z největších výjimek byla v oblasti grafik – výrobci jako Intel a ATI/AMD se rozhodli, že jejich hardware by měl být podporován svobodnými ovladači (většinou) a investovali zdroje do toho, aby se tak mohlo stát. NVIDIA spolupracuje mnohem méně a podpora pro její hardware tím odpovídajícím způsobem trpí. Zdá se, že problém s ovladači se blíží k vyřešení, ale nikdy bychom neměli zapomenout na snahu, která byla zapotřebí, aby se do tohoto stavu dospělo. NVIDIA by si v budoucnu naše peníze zasloužila mnohem více, kdyby tak velká snaha nebyla nutná.
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
18.1.2010 01:07
moo
Re: Jaderné noviny – 16. 12. 2009
18.1.2010 11:40
Laco
Re: Jaderné noviny – 16. 12. 2009
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
18.1.2010 14:11
18.1.2010 02:18
18.1.2010 15:37
18.1.2010 15:41
