Hlavní navigace

Názor ke zprávičce Triviální chyba umožňuje zabrzdění systemd od Lael Ophir - Ad IPC, Threading a asynchronní I/O je nějaká...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 4. 10. 2016 1:39

    Lael Ophir (neregistrovaný)

    Ad IPC, Threading a asynchronní I/O je nějaká specialita Windows? - myslíte že podobnost mezi WMI a D-Busem je čistě náhodná? :) Callbacky jsou také obvyklé ve Windows, naopak pro Unixy jde o "novinku". No a minimálně na Linuxu přišel použitelný threading po 13 letech trvání projektu (NPTL v kernelu 2.6), kdežto NT ho měly od první verze.
    http://powershelldistrict.com/wp-content/uploads/2014/09/MOW-WMI-browser.png
    https://upload.wikimedia.org/wikipedia/commons/b/bd/D-Feet.png

    Ad Textovými konfiguráky se dále zpravidla nastavují aplikace, které nemají žádné grafické UI, takže uvádět jako příklad emailový klient není právě na místě. Třeba v smb.conf či httpd.conf spoustu užitečných komentářů a příkladů určitě najdete - ano. To souvisí s tím, že vývoj Unixů zamrzl někdy začátkem devadesátých let, takže se GUI považuje za něco co může a nemusí být a může a nemusí fungovat. Díky tomu dodnes neexistuje obecně rozšířené admin gui pro ty věci, které se osmdesátých letech řešily editací komentovaného konfiguráku. Nové GUI aplikace samozřejmě od tohoto principu dávno upustily, takže konfiguraci LibreOffice (což je pár MB XML souborů) ručně editovat nemá smysl.

    Ad prakticky aplikovatelný benchmark, kdy by parsování konfiguráku něco znatelně zpomalilo - potřebujete snad benchmark na to abyste viděl, že vyhledání textu v konfiguráku je O(n) dopadne daleko hůř než v b-tree structure, kde je to O(log n)? V případě zápisu znamená změna jediné hodnoty přepsání celého souboru, což je z hlediska výkonu katastrofa. A jiné mechanismy správy konfigurací nepotřebují zamykat celý soubor (navíc jistě víte jak je to na Unixech se zamykáním souborů), když stačí zamknout jednu konkrétní hodnotu.

    Ad Kupřikladu windowsí registr, kde je do několika obrovských souborů soustředěno všechno možné od nastavení hardwaru, bezpečnostních politik po historii MP3 přehrávače je vskutku technologické veledílo. Takový SYSTEM.DAT o velikosti pár desítek až stovek MiB se určitě obsluhuje rychleji než párkilobytový konfigurák - Kupřikladu linuxí ext4, kde je na jednom obrovském volume soustředěno všechno možné od nastavení hardwaru, bezpečnostních politik po historii MP3 přehrávače je vskutku technologické veledílo. Musí to být neskutečně pomalé. Že je to nesmysl? Jistě, ale napsal jste dost podobný nesmysl. Ten váš párkilobytový konfigurák je na velikém FS, a přitom ten FS je v podstatě key-value database, kde key je cesta k souboru. Jakmile si uvědomíte, že otevření 1kB souboru na FS o velikosti 20MB nemá důvod být pomalejší než na FS o velikosti 2TB, tak uvidíte váš omyl.

    Mimochodem už jsem zmiňoval dconf a někdo linkoval Wikipedii. Koukněte se na stránky projektu. Jako důvod pro zavedení dconfu uvádějí mimo jiné to že pro čtení hodnot typicky není nutný syscall ani context switch, umožnuje efektivnější plánování I/O, a vyhýbá se silné fragmentaci FS plynoucí z použití stromu XML souborů s nastavením. Jako bonus získáte možnost ukládat jiné datové typy než string, (doufám že) řešení concurrency, a možnost rozumně číst a psát konfiguraci bez dohadování se který z toho nepřeberného množství formátů konfiguráků se zrovna používá (ok, komunita by se musela shodnout na dconfu nebo čemkoliv jiném, ale oba víme, že se neshodne nikdy na ničem).
    https://wiki.gnome.org/Projects/dconf#Design