Hlavní navigace

Názor ke zprávičce Hlasování k OOXML v ČR od LO - Samozřejmě utilita file nezkoumá jen první dva byte....

  • Aktualita je stará, nové názory již nelze přidávat.
  • 9. 9. 2007 17:08

    LO (neregistrovaný)
    Samozřejmě utilita file nezkoumá jen první dva byte. Má list, obsahující vždy offset, hodnotu která na daném offsetu musí být, a výsledný typ souboru. A soubory typu 669 poznává právě podle těch prvních dvou byte. Soubory typu RAR poznává podle toho, že začínají Rar!, přitom tak opět může začínat kde co. Jinými slovy toto řešení není dostatečně robusní.

    Optimalizace velikosti uložených dat je celkem problém. Pokud budete mít 100000 souborů velikosti 1kB (to by mohlo sedět k exportu Windows Registry), tak celá konfigurace zabere 4x více místa, než je nutné (u 4kB bloků, které se nejčastěji používají). U některých FS, jako FAT16, navíc máte limit na 64k souborů :), přitom u Windows bylo požadavkem, že na FAT16 musí běžet. Výkon při čtení je u konfiguráků problémem, protože když přistoupíte k souboru, tak se změni last access time souboru i všech nadřazených adresářů. A soubor musíte samozřejmě proseekovat, abyste našel danou hodnotu. Ano, můžete vypnout last access time pro daný FS, ale moc to neřeší. Změna hodnoty v konfiguráku je pak výkonově ještě větší katastrofa. Texťák totiž musíte v podstatě komplet přepsat (plus aktualizovat directory a případně nadřazené).

    Samozřejmě Windows Registry jsou strom. A jako každá podobná struktura (FS, binární strom, DB), i Windows Registry se zpomalují s růstem velikosti (a pochopitelně nikoliv lineárně). Nevím, kde vám řekli, že strom má konstantní počet iterací pro dosažení node, bez ohledu na počet prvků. To zpomalení je ale u Windows Registry nepodstatné. Už jsem vám psal, jak si ho můžete změřit.

    Binární cache je horší, než Registry. Je nutné jí synchronizovat s textovými konfiguráky, což je zbytečné a pomalé. Navíc pokud někdo neumí napsat binární konfigurační DB tak, aby se mu nezhroutila, jak potom asi píše FS? A děláte si tedy zálohu struktur FS do snadno čitelných textových souborů, abyste z nich mohl FS přestavět, když se zhroutí? Asi ne. Prostě máte FS implementovaný tak, že funguje, a je odolný vůči nejrůznějším selháním (a případně ho zálohujete na úrovni souborů). Podobně jsou ve Windows implementované Registry. Navíc když se vám poškodí Windows Registry, máte vždy jejich zálohu z posledního úspěšného bootu, kterou můžete během bootu nechat použít. Když se vám poškodí FS s konfiguráky, hledáte také Rescue CD a poslední zálohu systému.

    Při klonování je samozřejmě velmi dobrým nápadem pořídit image zdrojového stroje, ten umístit na síť (DVD, USB klíčenku, přenosný disk), a rozbalovat z image. Nebo vy si necháváte ten zdrojový stroj běžet na věky věků? Navíc u zapnutého stroje máte hromadu temp files atd. U větších firem celou problematiku řeší produkty pro lifecycle management, ale to je na jiné povídání.

    Používal jsem DEC Ultrix, OSF/1, HP-UX, Solaris, AIX, a několik odrůd Linuxu. Například na FUD prodejců DEC jen tak nezapomenu. Na technické problémy s OSF/1 také ne. Linux se postupem let trochu zlepšuje, ale pořád je to slabota. K VGA: když máte nainstalovaný driver pro svou kartu, shodíte systém, vyměníte HW, a zabootujete (obdoba naklonování počítače, kde cílový stroj má odlišnou grafickou kartu), skončíte na command line s chybovou hláškou. Teprve v příští verzi Ubuntu prý bude "neprůstřelný" X11 server, který vždy naběhne minimálně v SVGA režimu. Jinak X mi samozřejmě selhávají často. Například driver nv nerozdýchal, když jsem ke kartě připojil druhý monitor (jen zasunul kabel, nic jiného jsem nemělil); po startu X11 se prostě obraz rozpadl, a konec. A samozřejmě instalace driverů grafické karty pro Linux, to je velmi zábavná aktivita. Stáhněte si zdrojáky kernelu (proboha proč?), gcc, nějaké další balíčky, a kompilujte (proboha proč?). Je smutné, že si FSF bere uživatele jako rukojmí při prosazování své politiky. Technicky totiž není problém mít drivery grafiky se stabilním binárním rozhraním.

    Rsync roaming profiles neřeší. Nepomůže, že můžu specifikovat výjimky. Já potřebuji, aby se replikovalo jen to, co se replikovat musí, a abych nemusel ručně projíždět profily tisíců uživatelů, a vychytávat, co má nejspíš zůstat na lokále. Potřebuji, aby aplikace ukládaly lokální data na oddělené místo, a byly smířené s tím, že na jiném stroji tato data nebudou. To je ve Windows zajištěné (existují na to v profilu adresáře, je popsané jak je používat, a jejich správné používání je předpokladem certifikace Designed for Windows *). Unixy na to nikdy nebyly stavěné, takže s tím nepočítají.