Odpověď na názor

S těmi konfiguráky jsme si možná nerozuměli. Netvrdím, že by byly 2x náročnější, než Windows Registry. Tvrdím, že pokud se zvýší objem konfiguračního souboru na dvojnásobek, trvá vyhledávání hodnoty v něm dvojnásobnou dobu. Je to asi stejný rozdíl, jako mezi použitím databáze (Registry) a textového souboru s hodnotami (konfigurák). U zápisu/změny je to ještě výrazně horší. Ve zprávičkách dnes byl link na wiki openoffice, kde se řeší problémy s výkonem. Jedním z problémů je fakt, že načítání konfigurace trvá dlouho, a konfigurace je rozházená po spoustě souborů. Jetam i nějaký experiment, kde se konfigurace drží v databázi, a výsledek je o dost rychlejší. Netvrdil bych tedy, že konfiguráky nepůsobí problém s výkonem.
http://wiki.services.openoffice.org/wiki/Performance
http://wiki.services.openoffice.org/wiki/DbConfig

S dovolením Ext3 nemá podporu šifrování (ani podporu komprese, ani neumí ACID transakce, ani nemá změnový žurnál, atd).

Nevím, jak s instalací MySQL, ale instalace desktopových aplikací je zpravidla specifická pro dané distro. Pokud použijete balíček na jiném distru, budou chybět položky ve Start menu, aplikace nepůjde spustit, mohou mít problémy se závislostmi apod. Tedy asi ne v každém takovém případě.

Ano, pomocí skriptů nakonec ty služby nějak managujete. Bohužel API chybí. Samozřejmě popsaný problém se zámkem ve Windows nemůže nastat. Service Manager ví PID procesu, proces má nějaké entry points (typu metody ZastavSe), a pokud se servis neukončí, nemůže být znovu spuštěn. Ve skutečnosti je to trochu komplikovanější, protože v jednom procesu může běžet služeb více, ale pro ilustraci to stačí.

Wine toho času implementuje 57% funkcí Windows API, tedy podle vyjádření Wine. Wine je ještě pořád v beta verzi, a první ostrá verze bude kdo ví kdy. Podle wikipedie některé aplikace ve Wine fungují se slušnou stabilitou, a většina s "menšími problémy".
http://www.winehq.org/site/winapi_stats
http://en.wikipedia.org/wiki/Wine_%28software%29#Functionality

Samozřejmě souhlasím, že do počítačů se dnes hrabe hromada lidí, kteří jim nerozumí. Ale také si myslím, že problém je na straně dnešního IT. Vezměte si například hry. Když chcete hrát hru na konzoli, koupíte médium, vsunete do mechaniky, a jedete. Na počítači řešíte instalaci hry, její aktualizaci, řešíte jestli máte nejnovější drivery grafické a zvukové karty, nastavujete ručně ve hře grafické detaily atd. Podobné nesmysly řeší uživatelé každý den. Nefungují tiskárny, neotvírají se soubory, aplikace havarují, útočí viry. A nakonec fakt, že když s browserem vlezete na některé stránky, tak chytíte breberky, je také selháním IT jako oboru, a nikoliv uživatele. Uživatelé jsou tupí, a nezmění se. Budou používat počítače buď "na tupo", nebo vůbec (a když je nebudou používat vůbec, budou mít problémy udělat efektivně svoji práci, a navíc my dva budeme hledat nový job). Naším úkolem jako IT průmyslu je produkovat takové počítače, které se dají používat jako digitální foťák nebo mikrovlnka. Je to složité, ale auto nebo digitální foťák jsou také složité věci.

S tím 3D si nedělejte starosti ;). Hlavně, že jsme si to vysvětlili.

Autoři her by samozřejmě mohli psát pro OpenGL. Jenomže je to náročnější. Direct3D přináší na úrovni API některé věci, které se v C++ (a třeba C#) používají výrazně lépe, než OpenGL (které je určeno primárně pro jazyk C). Navíc DirectX poskytuje i služby typu obsluhy vstupních zařízení (x-osý joystick s force feedbackem), 3D zvuku apod. Samozřejmě když píšete něco, co má běžet na unixech, tak nemáte DirectX, a OpenGL spolu s dalšími knihovnami pro zvuk, vstupní zařízení a spol je jedinou volbou.