Názory k článku
Tři důvody proč se Linux hodí pro web servery víc než OS X

Však ona je pravda, že XML není _primárně_ určeno pro úpravu lidmi. Ale nepozdává se mi ten "příklad" nezformátovaného XML a navíc ještě bohatšího na informace.

Neřekl jsem, že má XML u fontconfig smysl (nebo že nemá).

Ale co si budeme povídat, konfigurační soubory "vlastnost=hodnota" taky nejsou ideální pro úpravy lidmi. Aspoň co se týče mě.

Osobně vidím tyto výhody v XML: 1) standardní formát; 2) téměř každý jazyk má knihovny pro jeho zpracování; 3) větší možnost skladování informací než v "klasických" konfigurácích; 4) když na to přijde, tak je i přehlednější, např:

XML:

 - modul 1
  - podmodul 1
   - vlastnost 1: nějaká hodnota
   - vlastnost 2: nějaká hodnota
  - ...
 - modul 2
 ...

Klasický styl:

modul1_podmodul1_vlastnost1 = nějaká hodnota
modul1_podmodul1_vlastnost2 = nějaká hodnota
modul2_podmodul1_vlastnost1 = nějaká hodnota
...

1) standardní formát

To mi připomnělo ten slavný citát Grace Hopperové na téma "standardy"... :o)))

2) téměř každý jazyk má knihovny pro jeho zpracování

Ano, a některé z nich jsou dokonce použitelné i bez úplné ztráty sebeúcty. :-) Stejně jako téměř každý jazyk má knihovny pro zpracování textu. Jsou dokonce jazyky, u kterých je napsání parseru pro text snad ještě snadnější, než zpracování XML vstupu, viz třeba haskellovský Parsec (vřele doporučuju podívat se na něj, až hodíš na FELu Javu do žita, možná se Ti budou líbit i některé jeho operátory :o)). Chvílemi mám pocit, že XML opravdu snad vymysleli kvůli C++ a Javě. :]

3) větší možnost skladování informací než v "klasických" konfigurácích

Opravdu nevím, co tohle znamená. :-)

4) když na to přijde, tak je i přehlednější, např:

A třeba takové

modul1 {
 podmodul1 {
    vlastnost1="něco"
    vlastnost2="něco jiného"
 }
 podmodul2 { tohleje="úplnákravina" }
}

...by nestačilo? To první, co píšeš, není XML, nemá to komplementární zobáčky. :-) To už bych za XML mohl prohlásit Lisp nebo Algol - taky mají hierarchickou blokovou strukturu (jeden se závorkami kulatými, druhý se složenými).

> Stejně jako téměř každý jazyk má knihovny pro zpracování textu.

Ano, ale to znamená napsat si to sám. :-) (Nebo si opatřit existující dostupné knihovny a doufat, že nemají svá "specifika".)

> Jsou dokonce jazyky, u kterých je napsání parseru pro text snad ještě snadnější, než zpracování XML vstupu

Ano, ale v těchto jazycích je obvykle složité napsat jiný program než parser (aspoň z toho, co jsem viděl). I když... Tyto jazky využívají vesměs jen lidé, co jim opravdu rozumí, ale těch je zase málo.

> možná se Ti budou líbit i některé jeho operátory

K "novým" operátorům mám nedůvěru od dob, co jsem se poprvé (a naposledy) pokoušel proniknout do Perlu. :-)

> Opravdu nevím, co tohle znamená. :-)

To znamená, že se tam lépe umístí i něco složitějšího než je řádka textu. A můžeš s tím lépe pracovat, např. pomocí atributů atp. Budu se mýlit, když řeknu, že do jedné vlastnosti "klasického" konfiguráku lze zapsat jen atomickou hodnotu?

Uzel XML je podle mě jako řádek tabulky a klasická vlastnost konfiguráku je jako jedna buňka (hodně zhruba řečeno :-)).

> To první, co píšeš, není XML, nemá to komplementární zobáčky.

Ne, to opravdu nebylo XML. :-) Tím jsem jen naznačil jednotlivé uzly (zobáčky sem nejdou vepsat jen tak, musejí se převést na nějaké HTML entity -- a kvůli nim se mi nechtělo otevírat textový editor). To jen tak pro pořádek :-)

> modul1 {

Ale to už se pomalu dostáváme zase ke XML. Jen tam místo zobáčků jsou složené závorky. Standardizujme to, vytvořme pro většinu jazyků knihovny a... a pojmenujme to XML 2. :-)

V žádném případě ale nechci, abyste si to brali jako fundovaný názor experta na tuto problematiku. Mluvil jsem o zkušenostech, které jsem sám měl: nic víc, nic míň.

Ano, ale to znamená napsat si to sám. :-) (Nebo si opatřit existující dostupné knihovny a doufat, že nemají svá "specifika".)

Toho není ušetřeno ani XML. A pokud nepoužiješ třeba XPath, což něco stojí (minimálně dokument v paměti a kus výkonu), tak si ten kód na SAXí eventy stejně musíš napsat sám. Where is the difference? Když jsem něco takového kdysi psal, fakt mi nepřišlo, že bych si tím něco zjednodušil.

Ano, ale v těchto jazycích je obvykle složité napsat jiný program než parser (aspoň z toho, co jsem viděl).

Zato v Javě jsem si připadal, že se v ní píše všechno stejně špatně. :-) Ne všichni musejí tento Tvůj názor sdílet.

To znamená, že se tam lépe umístí i něco složitějšího než je řádka textu. A můžeš s tím lépe pracovat, např. pomocí atributů atp. Budu se mýlit, když řeknu, že do jedné vlastnosti "klasického" konfiguráku lze zapsat jen atomickou hodnotu?

Máš fakt malou fantazii. :-) Začínám chápat, proč máš rád XML. Jsi zvyklý uvažovat v mezích jeho konceptů, a proto nevidíš, co se dá řešit jinak.

Kupříkladu mi není jasné, jak by "můžeš s tím lépe pracovat, např. pomocí atributů atp." mělo být relevantní. Atributy můžu mít kdekoli, ani tomu nemusím říkat atributy. Chvílemi mi dokonce přijde, že dělení na atributy a elementy je jen pro zlost. Chvílemi opravdu není jasné, jestli co v datovém formátu nacpat do atributu a co do elementu jako PCDATA.

Tohle dokonce vidím jako jeden z viditelných symptomů toho, že se XML často používá k něčemu, pro co nebylo navržené: V dokumentech platí, že PCDATA je textový obsah dokumentu, kdežto atributy určují způsob jeho zobrazování (nebo to z něj, co nedokáže vyjádřit hierarchická struktura a názvy elementů, případně jiné neobsahové věci, třeba jedinečná ID), takže není co řešit. Ale kde je hranice ve výměnném datovém formátu? Pokud je ta distinkce v (údajně) "obecném" metaformátu natolik neintuitivní a nesamozřejmá, že tisíce lidí cítí potřebu rozebírat to kolem dokola, neznamená to, že je něco špatně? Tímto Ti děkuji za nahrávku na smeč. :-)

Žádný "klasický" konfigurák navíc neexistuje, protože nic takového není definované. A nikdo Ti nebrání udělat si pro neatomické hodnoty třeba syntaxi hodnoty = ["Jedna", "Dvě", "Tři"], a věřím, že slušný parser alternativu mezi atomickou hodnotou a seznamem hodnot zvládne na pár řádků. :-)

Ale to už se pomalu dostáváme zase ke XML. Jen tam místo zobáčků jsou složené závorky.

Nedostáváme. Zatím jsme pouze na úrovni jednoduchého jazyka s blokovou strukturou. Jestli nechceš flat file, níž se jít už moc nedá, a pokud jdeš výš, můžeš si vybírat, jaké struktury zavedeš. Tvrdím, že pokud se jedná 1) o jazyk určený k ručním úpravám, 2) bez ambic, které má XML (rozšiřitelnost, výměnný formát, ve kterém je víc stryuktury, než textového obsahu) a obzvlášť 3) s malou až střední gramatikou (na které se toho nedá moc zkazit - nebavíme se tu o C++! :)), je blbost sahat ihned ke XML.

Standardizujme to, vytvořme pro většinu jazyků knihovny a... a pojmenujme to XML 2. :-)

Směle do toho, nadšený javisto! :-D

> Ne všichni musejí tento Tvůj názor sdílet.

Samozřejmě; je to můj názor a nikomu ho nenutím.

> Atributy můžu mít kdekoli, ani tomu nemusím říkat atributy. Chvílemi mi dokonce přijde, že dělení na atributy a elementy je jen pro zlost.

Uznávám, že někdy není jasné (při návrhu), co jsou atributy, a co obsah elementů (jsou o tom snad i celé knihy :-)). Pokud se ale lidé dělající na určitém projektu shodnou, jak postupovat (aby nebyl každý pes jiná ves), není problém. Je to podle mě stejná prkotina jako shodnout se, jestli složené závorky za podmínkou patří na stejný řádek jako podmínka...

> Žádný "klasický" konfigurák navíc neexistuje, protože nic takového není definované.

Proto jsem to psal v uvozovkách.

Pro svou vlastní potřebu bych si jej (velmi zhruba) definoval asi takto: klasický konfigurák se skládá z páru klíče a hodnoty. Klíč je řetězec neobsahující mezery (ani jiné bílé znaky) a znaménko "rovná se". Hodnota je libovolný řetězec neobsahující odřádkování. Pár klíče a hodnoty je na jednom řádku (v tomto pořadí), přičemž klíč je od hodnoty oddělen znakem rovná se. Atd. (je mi jasné, že je to velmi nepřesné).

> A nikdo Ti nebrání udělat si pro neatomické hodnoty třeba syntaxi hodnoty = ["Jedna", "Dvě", "Tři"], a věřím, že slušný parser alternativu mezi atomickou hodnotou a seznamem hodnot zvládne na pár řádků. :-)

Ano, ale to jsme zase u toho, co jsem označil za XML 2. :-)

Sice si zpracuješ ten "klasický" konfigurák jako takový (rozdělíš na klíče a hodnoty a někam uložíš), ale pak musíš ještě zpracovávat ty hodnoty. A pokud je každá hodnota složena z hodnot, její hodnota složena z hodnot a tak dál, tak se do toho už zamotáš (čti: já bych se do toho zamotal).

... a nakonec zjistíš, že jsi vytvořil uzly XML. Jen jsi je zapsal jinak. Nemám malou představivost, naopak: umím si představit, jak je tohle neefektivní. :-)

A co se týče rychlosti, nevím, nevím. Nejspíš by se to řešilo pomocí nějakých regulárních výrazů. Pokud by byly složitější (nebo jich bylo hodně), už by se to na výkonu asi projevilo. Zejména, pokud bys to implementoval v interpretovaných jazycích (můj odhad).

A nejhorší je náchylnost k chybám. Záladní věci si ošetříš, ale téměř vždycky se najde koumák, co do toho napíše něco, co nemá. A co program nezvládne.

> je blbost sahat ihned ke XML.

Souhlasím s tím, že se někdy objevují snahy typu "Máme trochu času navíc... Tak něco přepíšem do XML." a že to není dobře. :-)

Mimochodem, mám dojem, že jsme spolu v poslední době někde (živě) mluvili. Je to možné?

Pokud se ale lidé dělající na určitém projektu shodnou, jak postupovat (aby nebyl každý pes jiná ves), není problém. Je to podle mě stejná prkotina jako shodnout se, jestli složené závorky za podmínkou patří na stejný řádek jako podmínka...

To tedy určitě není, protože preference v umístění složené závorky nezmění gramatiku jazyka, kdežto umístění kusu dat do atributu místo do elementu má pro schéma docela vážné následky, kupříkladu kvůli atomicitě atributů vyvstává nutnost hacků typu Card:email.type="internet;pref;work", na kterou nás upozornil pan Kvasnička o kus níže, a trošku problematické je vkládání podelementů do atributu :-) - problém je to hlavně ve chvíli, kdy zjistím, že něco, co jsem chtěl jako atribut, chci ve skutečnosti jako element, protože to je zásah poměrně brutální (jiný handling v SAXu, jiný handling v XPathu...). Kdežto závorku v Cčku přeformátuju hned. :-) Takže nevím, jak jsi k tomuhle srovnání dospěl.

... a nakonec zjistíš, že jsi vytvořil uzly XML. Jen jsi je zapsal jinak. Nemám malou představivost, naopak: umím si představit, jak je tohle neefektivní. :-) A co se týče rychlosti, nevím, nevím. Nejspíš by se to řešilo pomocí nějakých regulárních výrazů. Pokud by byly složitější (nebo jich bylo hodně), už by se to na výkonu asi projevilo. Zejména, pokud bys to implementoval v interpretovaných jazycích (můj odhad).

Proč by to mělo být neefektivní? Pomocí regulárních výrazů stejně napíšeš jen lexer (to už jste brali, ne? ;-)), a i tenhle stavový automat bude jednodušší a rychlejší pro jakýkoli rozumný "tradiční" jazyk než pro XML. Samozřejmě, že vyšší vrstva to svou mírně vyšší složitostí trošku vykompenzuje, ale pokud se neřeší C++, tak nechápu, kde bereš ten názor, že XML je rychlík. Jednou jsem zkoušel parsovat 2MB XML soubor přes Expat, který by snad měl být nejrychlejší, a ve skutečnosti byl osmkrát pomalejší, než když jsem data převedl do izomorfních S-výrazů. Ne, kvůli rychlosti se XML opravdu nepoužívá, to už spíš má smysl jít do pohodlnost a zaměstnat na tahání dat XPath a XQuery, když už to nebude rychlé, aspoň to bude rychle. :-)

A nejhorší je náchylnost k chybám. Záladní věci si ošetříš, ale téměř vždycky se najde koumák, co do toho napíše něco, co nemá. A co program nezvládne.

To je nevýhoda složitých gramatik. XML má "gramatiku" (ehm) celkem jednoduchou (i když taky ne triviální, přinejmenším vezme-li se v úvahu požadavek na korektnost, aspoň to tvrdí Uche Ogbuji), zato přesouvá zodpovědnost za strukturu "výš do aplikace". Skoro jsem v pokušení říct "pro jednoho '(XML) parser', pro jiného jenom lexer". :-) Existence XML nijak zázračně neodbourá potřebu detekce struktury, nutnost zotavení z chyb a podobně.

Validace XML je (jako každý automat) schopna podat odpověď na otázku zjišťovací, ovšem v případě negativní odpovědi inteligence výstupu povětšinou kulhá. Umí vůbec nějaký schémovací jazyk definovat "chytré" a opravdu užitečné chybové zprávy pro konkrétní selhání? Zatím jsem z XML nástrojů viděl lézt jen šílenosti typu "element XYZ má mít tvar (pět řádků něčeho, co vypadá jako DTD), ale v souboru má na řádku abc tvar (pět řádků něčeho, co vypadá na prvních sedm pohledů úplně stejně)". Proto mi přijde, že i co do inteligentních hlášek platí "co si neudělám, to nemám".

Mimochodem, mám dojem, že jsme spolu v poslední době někde (živě) mluvili. Je to možné?

Vyloučeno. :-) Nikdy jsme se nepotkali, zatím jsem si všechny myši pamatoval. :-) Navíc mám ropuchu a nechodím mezi lidi. :-)))

> Takže nevím, jak jsi k tomuhle srovnání dospěl.

Ano, je to samozřejmě "jinej level", ale princip je stejný.

A hlavně: všechno jde navrhnout špatně. A nemusí to být jen XML soubor. Co když zjistíš, že jsi špatně navrhl to "["jedna", "dva", "tri"]"? Problémům se prostě nevyhneš, pokud to navrhneš (a tedy nejspíš i zanalyzuješ) blbě. :-)

U dat, u kterých hrozí, že budou mít "podhodnoty", je to samozřejmě jiná věc a nezávisí na tom, co si vývojáři vyberou. Já ale mluvil o případech, kdy si člověk opravdu může vybrat.

> to už jste brali, ne?

Nebrali; já si totiž ze školy po necelém semestru odskočil do praxe. Podal jsem si přihlášku i na příští rok, takže to možná budeme brát. :-)

> kde bereš ten názor, že XML je rychlík.

To jsem v žádném případě nemyslel. A souhlasím s tím, co píšeš dál, tedy že to bude nikoli (hodně) rychlé, ale rychle. Podle mě je to velmi přesné.

Na zbytek se necítím být kompetentní odpovídat (i u toho předchozího to bylo velmi, velmi diskutabilní :-)).

> Vyloučeno. :-) Nikdy jsme se nepotkali, zatím jsem si všechny myši pamatoval. :-) Navíc mám ropuchu a nechodím mezi lidi. :-)))

Nechodíš mezi lidi? Nevadí. Však jsi sám řekl, že jsem myš. :-)

A jinak já mám taky tu ropuchu, a proto mi bylo divné, že bychom se někde viděli. :-)

Piloti si za letu potřebují v reálném čase číst maily? :-) Jinak jestli jde o ty letecké návody, na které to zřejmě používají, tak získat v řádu sekund informace z nanejvýš pár desítek mega dat není zrovna hrdinství. Na druhou stranu je mi jasné, že i tady se vyplatí použít hotové řešení a nedělat žádnou extra specialitku.

a... a pojmenujme to YAML :-)

> Ano, a některé z nich jsou dokonce použitelné i bez úplné ztráty sebeúcty. :-) Stejně jako téměř každý jazyk má knihovny pro zpracování textu.

To me pripomina povidacky o jedne nejmenovane katedre MFF, kde se rozhodli, ze nove verze jejich nastroju bodou pouzivat XML pro datove soubory. Vzhledem ke stavu XML parseru to nakonec parsuji regularnimi vyrazy. Vzhledem k tomu, ze XML jde takto spolehlive parsovat jen velice tezko, tak ty nastroje spolehlive funguji jen na podmnozine XML, do ktere spadaji soubory generovane temi nastroji.

A to se skutečně stalo, nebo to jsou, jak říkáš, "povídačky"? :)

Vypravela mi to osoba, ktera tam nejake nastroje implementovala. Ale za presnost me reprodukce nerucim.

Jinak, vybavila se mi ta trefná poznámka: "Někteří lidé mají problém. Rozhodnou se nasadit XML. A najednou mají problémy dva." :-)

No už se těším na to, až někdo do chudáka Mutta kvůli vCardu v XML zahákuje XQuery, ideálně i s JVM... ;/ Tohle přitom nevypadá až tak složitě. :-)

Padla řeč o XQuery. ;-) O jiných implementacích XQuery než javovských zatím nevím. V tomhle je Java opravdu vybavena dobře - i když obecně bych si to tvrdit nedovolil. :-] (Třeba schemovský ekvivalent XPathu 1.0 má schopnosti XQuery už roky, protože z něj prozíravě udělali de facto rozšiřitelnou kombinátorovou knihovnu.)

Server Manager... to je ta věc z Windows NT 4.0, pokud mě paměť neklame. Zkuste někdy MMC, například applet Computer Management. YaST je pěkný pokus, bohužel poněkud nedodělaný.
S XML to má společného to, že když provádíte změny konfigurace v GUI, nepotřebujete čitelný konfigurák s komentáři popisujícími parametry. Nebylo to jasné z původního příspěvku?

Konfigurace mého systému má exportovaná v textu asi 80MB. Samozřejmě to lze rozsekat do hromady maličkých souborů, a pak tvrdit, že je to super, ale jistě cítíte, že to není to pravé.
Vícenásobný přístup ke konfiguraci je aktuální všude, kde běží více instancí té samé věci, nebo kde tutéž konfiguraci čte více komponent. Opravdu nemluvím o OLTP DB ;)

Samozřejmě LDAP lze použít jako storage konfigurace. Ale nějak mi nepřipadá, že by se tak ve velkém dělo.

Windows 2008 používají Windows Registry pro většinu nastavení. LDAP potom drží databázi účtů uživatelů a počítačů (AD doménu), a nově pravda i nějakou konfiguraci sdílenou mezi stroji v doméně. SAM nemá souvislost, protože nejde o nastavení. A když jsme u textových konfiguráků, kde jste je našel?

Pokud máte X formátů konfiguračních souborů, a používáte jejich editaci namísto administrativního interface, tak je lehký wake up call zcela na místě. Pochopitelně pokud dostatečně dlouho děláte s unixy, tak vám přijde, že je to zcela v pořádku. A kupodivu vám nepřijde divné ani to, že jste nejspíš nikdy neviděl konfigurák svého OpenOffice, KMailu a dalších aplikací, které spravujete čistě z GUI, stejně jako ve Windows. A možná znáte i GConf, který je prakticky obdobou Windows Registry (jen jako backend používá konfiguráky s binárními indexy místo databáze).

SeDebugPrivilege: Required to debug and adjust the memory of a process owned by another account. Upozorňuji, že "owned by another account" se týká instance procesu (ne práv FS); jde o kontext, ve kterém byl proces spuštěn.