Odpověď na názor

Přidávání klíčů v Registry je obdobou zakládání souborů na FS, stejně tak přidávání hodnot do klíčů nebo změna dat (nic z toho Registry výrazně nezpomaluje). U konfiguráků je naopak změna hodnoty nebo přidání hodnoty věcí, která je velmi pomalá, a při prodloužení konfiguráku na dvojnásobek trvá vyhledání hodnoty v něm dvojnásobně dlouho.

Pokud prodloužíte soubor, je poměrně pravděpodobné, že dojde k jeho fragmentaci. Mimochodem srovnání souborových systémů na Linuxu a ve Windows vyzní pro Linux dost mizerně. Jeden FS umí žurnál a quoty, další umí ACL a žurnál, jeden umí kompresi, další umí šifrování... Ve Windows máme NTFS, které má žurnál, ACL, kompresi, quoty, a umí plně ACID transakce (změna v souboru A, změna v souboru B, update v databázi, změna v souboru C, poté commit nebo rollback).

Konfiguraci vztaženou k uživateli ukládají Windows v HKEY_CURRENT_USER, což je Registry Hive (řekněme DB soubor), který sídlí v profilu uživatele.

K tomu, abyste mohl udělat například přidání uživatelů, které jsem popisoval, nepotřebujete žádný proprietární SW (vyjma Windows jako takových). Formáty MS Office jsou založené na technologii OLE Document, což je vyšší úroveň abstrakce, než běžná C/C++ binární struktura (Word neví, jak konkrétně jsou objekty reprezentovány v souboru). Má to své podstatné výhody, stejně jako například kontejnerový formát TIFF. Pochopitelně pokud neumíte rozhraní OLE Document, máte při implementaci celkem problém. Naštěstí to máme také textové RTF, a XML-based OOXML.

BSD a Linux jsou naopak v podstatě jedna platforma (UNIX), která se časem rozpadla do mnoha různých variant, které jsou jen omezeně kompatibilní. Ohledně 5 adminů jsme si nerozuměli. Když měl systém 5 adminů a 3 služby, nebylo třeba držet seznam běžících služeb (prostě běžel proces), ani je nijak ovládat (každý admin věděl, jak je spustit ručně). Mít nějaký Service Manager by v té době bylo jako jít s kanónem na vrabce. Časy se změnily, ale unixy bohužel ne.

Apache si drží zámek na aplikační úrovni, pokud si pamatuji. Když ho spustíte, zapíše si do nějakého souboru, že běží, a při případném dvojím startu to z toho souboru zjistí.

S Wine to je jako, byste tvrdil "moje elektronkové rádio hraje dobře, a je to jen o tom, jak umíte zacházet s pájkou, a jak znáte obvody". Ano, to je jistě možné. Ale stejně jako většina posluchačů rádia nechce pájku ani vidět (pokud už ví, k čemu taková věc je), většina počítačového lidu se nechce hrabat ve Wine. Nakonec všichni chceme používat počítače jako mikrovlnku, mixér, nebo foťák. Tedy až na uživatele vi ;)

Ne, DVD není jen o CSS. MPEG2 dekodér můžete implementovat "nezávisle", ale přesto použijete patentované technologie.

S těmi 3D primitivy se nám to nedorozuměním vzrhlo v komedii. Primitivem se v grafice rozumí nejjednodušší prvky, ze kterých se staví další objekty. 3D primitivy na úrovni Direct3D a OpenGL rozumíme body, úsečky, trojúhelníky, a některé jejich jednoduché složeniny (třeba pás navazujících trojúhelníků). 3D akcelerace na PC pracuje primárně s trojúhelníky, protože jsou nejúspornějším způsobem, jak popsat plochu ve 3D prostoru. Pro ilustraci si představte, že složíte 3D model postavy z pár desítek trojúhelníků. Každému trojúhelníku určíte barvy v jeho rozích, a plocha trojúhelníku bude postupným přechodem mezi těmi barvami. Takhle můžete vytvořit už celkem věrný 3D model. O kus dále se dostanete, když trojúhelníky místo jednoduchého vybarvení potáhnete nějakým obrázkem, tedy texturou. Shadery by byly mimo rozsah mého příspěvku. Každopádně Direct3D i OpenGL jsou interfacem, který slouží k vykreslování 3D výše popsaných primitiv, ze kterých se skládají složitější útvary. Když jste mluvil o OpenGL ve Windows, měl jsem za to, že máte konkrétní výhrady k jeho implementaci, jen jste je nesdělil.