Odpověď na názor

Vyčištěním Registry do poinstalačního stavu odstraníte přesně to, o čem jsem mluvil - reference na řadu komponent, včetně těch kousků od nVidia (a RarLab, WinZIP, 7Zip, a tísíců dalších).

Ano, shodneme se, že přidání konfiguráku zpomalí FS minimálně. Pokud přidáte klíč do Registry, dopadne to stejně, a zpomalení nepoznáte.

Konfiguráky nemají typivky milion řádků, ale pro demonstraci jejich pomalosti je to pěkný příklad. Samozřejmě pokud má konfigurák 10kB, nebo 100kB, je to v principu podobný problém, jen menšího rozsahu. Navíc samozřejmě dochází k fragmentaci konfigurace (prodloužení souboru vede k tomu, že bude na disku uložený nesouvisle).

Ano, konfigurace Windows je velká. To má dva důvody. Prvním je to, že Windows mají komponentový systém, a informace o COM komponentách se drží v Registry. A druhým je fakt, že se ve Windows dá obrovská spousta věcí nastavit (byť si to uživatelé unixů nemyslí). Navíc pochybuji, že do kompletní konfigurace počítáte databázi balíčkovacího systému (která je u RPM binární), konfiguráky mimo /etc (třeba ty, které píše Oracle ve svém stromu), konfiguráky uživatelů atd.

Možnost svobody a svobodné volby je zástupné téma. Proč? Podívejme se, co potřebujete, abyste mohl přidat uživatele z Excelu. Na prvním místě systém musí mít nějaké API pro přidávání uživatelů (pokud nechcete z GUI spouštět command line utility a parsovat jejich výstup, což je prostě hnus). Na druhém místě musí Excel nabízet skriptovací prostředí, které umožní toto API volat (tím prostředím je Visual Basic for Applications, ale v principu to může být VBS, PERL, Python, nebo cokoliv jiného). Ani jedna z těchto věcí nijak nesouvisí se svobodou, svobodou volby apod. UNIXy nemají API pro věci typu přidávání uživatelů (získání seznamu procesů, získání seznamu a ovládání deamonů) proto, že takové API v době dřevních unixů nikdo nenapsal, a od té doby se k tomu nikdo neodhodlal, protože se vývoj platformy zpomalil až zastavil. A samozřejmě je to komponentový model, který Microsoft zavedl se svým COM. Ani jeho obdoba na dřevních unixech nebyla, a od to doby se toho moc nezměnilo (byť KDE demonstrujke jistou snahu, viz KOM/OpenParts, KParts/DCOP). Díky COM (resp. OLE) je ve Windows možné do Corel Draw vložit rovnici napsanou v MS Equation Editoru, tabulku Excelu, nebo naopak do Excelu objekt Corel Draw. Díky COM (resp. DCOM) je možné z VBS skriptu spustit objekt (třeba MS Word) na vzdáleném stroji, a používat ho. Nic z toho není v rozporu se svobodami uživatele nebo vývojáře. Je to jen obrovská spousta práce, kterou vývojáři platformy investovali.

Pro zastavování služeb na Linuxu můžete použít skripty. Bohužel na každém distru (obecně na každém unixu) jsou jinde. Není to objektové, není to použitelné z kódu, a je to velmi nešťastné řešení. Ve Windows máte Service Manager. Když nainstalujete binárku služby, zaregistrujete jí pomocí volání API (to může provést command line utilita, když na to přijde), nastavíte jméno služby, display name, kontext pod kterým poběží, co se má dělat když služba odpadne (například jí restartovat, a když požád neběží, rebootovat stroj, nebo zavolat nějaký program). Service Manager vám řekne, jaké služby v systému jsou, v jakém jsou stavu, a umožní vám je ovládat. API je popsané stejně, jako máte na unixech popsanou libc (jenom zřejmě podrobněji), a samozřejmě ho můžete používat, jako jakékoliv jiné API. Opět tu nikde není problém svobod. Problém je, že dřevní unixy neznaly pojem služba. Daemon byl proces, jako každý jiný, který se spouštěl v nějakém startup scriptu. Žádná registrace služeb a jednotný způsob jejich ovládání tehdy nevznikl, protože ty služby běžely na serveru tři, a server měl 5 administrátorů, kteří okolo něj chodili v galoších a bílých pláštích. Později vznikly skripty, které služby umožňují ovládat, protože situace nebyla dále udržitelná (bohužel na různých unixech různé skripty). Je to slabá náplast. A opět to není o svobodách, ale o dlouholeté stagnaci platformy.

Wine je způsob, jak se skřípěním zubů rozchodit část funkcí Windows aplikace na Linuxu. Otázka je, proč to vůbec dělat. Obdobně je možné rozchodit unixové aplikace na Windows pomocí Services for UNIX (měl jsem na stroji jednoduchý WM, unixový Gimp a pár dalších aplikací). Demonstrace je to pěkná, ale v praxi je takový přístup krajně nepraktický.

Pokud neznáte MSDN, zkuste tyto linky (nevím, jestli půjdou z jiného browseru, než MSIE):
http://msdn2.microsoft.com/en-us/library/aa363858.aspx (Win32 API, funkce CreateFile, obdoba uniuxového open)
http://msdn2.microsoft.com/en-us/library/system.windows.controls.button.aspx (.NET Framework 3.5, třída Button; všimněte si vlevo ve stromu Methods, Properties atd., a dole v See Also příkladů a konceptů)

Výše uvedené linky jsou typickými příklady. Jistě uznáte, že srovnávat takovou dokumentaci se stránkami man postrádá smysl. Navíc jde o webovou verzi MSDN. Lokální verze má lepší vyhledávání, filtry obsahu, filtry jazyka (ty můžete viděl i na webu - u Buttonu si nahoře vyberete, jestli chcete vidět i definice a příklady pro J#, VB.NET apod). Man může některým lidem stačit, pokud nepotřebují přehled, vysvětlení konceptů, příklady, komentáře apod. Otázka je, proč by se měli spokojit s málem, když mohou za pár korun dostat lepší dokumentaci a daleko širší platformu, a řádově větší počet potenciálních zákazníků.

DVD dekodér není jen problémem CSS. Jde také o fakt, že MPEG2 dekodér obsahuje patentované technologie, údajně cca 640 patentů. Každý patent drží někdo jiný, a vy musíte získat souhlas všech zúčastněných (zpravidla placený ;)), abyste směl MPEG2 dekodér legálně implementovat. Firmy zabývající se IP od těchto institucí a lidí odkupují práva k jejich patentům, a nabízejí je pohromadě jako práva k MPEG2. Tady se dozvíte, jaké patenty jsou ve hře, a na kolik vás přijdou.
http://www.mpegla.com/m2/m2-patentlist.cfm

S OpenGL jste začal vy. Samořejmě OpenGL je o vykreslování 3D primitiv (nebo máte jiný názor?). Direct3D obdobně. Jenže DirectX je nadmnožina Direct3D.