Odpověď na názor

Mohu se zeptat, jak jinak, než podle přípony zjistíte, jakého typu je soubor na disku? Můžete použít magic numbers, jako utilita file. Výsledkem ale bude hromada omylů, protože klíčovou sekvenci může obsahovat prakticky libovolný soubor (třeba první dva byte souboru mohou být "if", a nemusí to být Composer 669 Module sound data). Samozřejmě kontextové menu tvořené statickou konfigurací je poměrně nuda. NSPlugin zní lépe. A teď mi řekněte, co se stane, když budete mít nainstalováno pár desítek NSPlugin-ů, a některé z nich budou pomalé. Odezva Konqueroru potom samozřejmě bude horší. Navíc ty pluginy budou buď zavedené od spuštění Konqueroru, a tedy prodlouží jeho start a zaberou permanentně nějakou paměť, nebo se instancují při každém použití, což je zase pomalé. A když budete mít v konfiguraci Konqueroru referenci na pár stovek či tisíc již odstraněných pluginů, i to bude stát čas. Velmi podobně, jako ve Windows. Jenom do svého Konqueroru asi neinstalujete všechny shity, co uvidíte (a asi jich bude existovat o pár řádů méně,než pluginů pro Windows Explorer).

Souborový systém ukládá efektivněji, než registry? A všiml jste si třeba, že na FS je místo zabrané souborem kvantované po blocích? Že FS udržuje last modification a last access time pro každý soubor, a přečtení či modifikace souboru znamená změnu příslušných time stamps v položce directory, i v nadřazených directories? Dále v konfiguračních souborech se samozřemě hledá. Například když máte komponentový model, tak je třeba mít seznam těch komponent, a odkazy na konkrétní binárky (plus konfigurační informace typu verze, impersonation atd). Těch komponent máme na Windows na každém stroji desítky tisíc (sdílené dialogy, DB komponenty, kompresory a dekompresory multimédií, průvodci, pluginy do browseru, property pages...), a aplikace jsou z nich poskládány. Poskytuje to neuvěřitelnou flexibilitu. Linux je pravda v této věci zatím v plenkách.

Nebo seznam MIME typů a akcí k nim příslušejících. Na mém stroji je zaregistrováno cca 1100 druhů přípon souborů, a velké procento z nich má registrované akce typu open, print, extract, context menu handler, atd. Přece tohle nebudete mít trvale zavedené v paměti. No a v textovém souboru zase budete jen permanentně seekovat. Tohle jsou důvody, proč má KDE svůj KConfig, který z konfiguráků sestaví binární "registry", se kterými pak aplikace pracují. Pochopitelně než přišel na Linux desktop, bez obdoby Windows Registry se bylo možné obejít; ale i na tak primitivním platformě, jako je Qt/KDE, ta potřeba už existuje.

Kopírování uživatelů se nejen nedělá, ale bylo by bezpečnostním problémem. Hash hesla jinak shodného uživatelského účtu by měl být na každém počítači jiný (to je důvod, proč mají Windows stroje unikátní SID). Nevím, jak vypadalo klonování, kterého jste se zúčastnil, ale v praxi se pustí Setup Manager, kde si vyberete, co se má na cílové instalaci provést (vytvořit partition, vytvořit page file, provést re-scan HW konfigurace, zobrazit dialog), pak řeknete, že se to spustí po rebootu, provedete shutdown, a jdete klonovat. Pokud má třeba cílový stroj odlišnou video kartu (a image pro ní má driver), tak bude automaticky použita (nebo dojde na SVGA fallback). V Linuxu skončí stroj po startu na command line schybovou hláškou, a určitě si sám nevybere driver videokarty. Navíc pro Windows existuje hromada SW pro deployment na desktopech, kde si vyberete skupinu strojů, řeknete, že na ně přijdou nějaké aplikace (balíčky včetně konfigurace), a víc se nestaráte. Linux je na desktopu velmi nezralý.

Unixy samozřejmě roaming profiles neumí. Jak rsync pozná, co je cache browseru, co je nastavení ICQ klienta, a co jsou dokumenty uživatele? Takovou cache browseru (a řadu dalších podobných věcí) totiž nemá smysl zbytečně tahat na síť a zpět. Naopak nastavení se tahat musí, stejně jako dokumenty. Windows v profilu mají vyhrazené adresáře, které se nereplikují, viz SDK. To je totiž pro použitelnost replikace profilu celkem zásadní, na rozdíl od protokolu (který může být různý pro připojení na Novell a Windows servery).