Hlavní navigace

Tři důvody proč se Linux hodí pro web servery víc než OS X

Sdílet

Adam Štrauch 1. 7. 2008

Na linux.com se Johannes Truschnigg zabývá otázkou co je vhodnější systém pro web server. Johannes přišel se třemi zajímavými body, ve kterých je Linux lepší než OS X. V prvním bodě naráží na problémovou instalaci některých serverových programů. Ty totiž občas nejsou dostupné v klasickém .dmg balíku a tak je nutné stáhnout zdrojové kódy a zkompilovat. Pokud pak dojde k aktualizaci, musí se o tyto programy starat administrátor sám. Druhý bod se věnuje výchozímu nastavení některých balíků a upozorňuje na zvláštní strategii Apple při konfiguraci serverových programů. Poslední bod upozorňuje na skutečnost, že i když OS X získal nálepku UNIX, není to UNIX stejně jako Linux, nebo i další systémy UNIXového typu. Jako příklad je uvedeno, že na /etc/resolv.conf reagují pouze některé aplikace, nebo že neexistuje žádný System V init a služby se zavádějí pomocí daemonu launchd. Ten umí sice automaticky spouštět/zasta­vovat/restarto­vat služby podle různých podmínek, ale jeho konfigurace je uložena v XML souborech a tím se stává pro člověka mnohem hůře čitelná.

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 1. 7. 2008 10:23

    Tomas Matejicek
    Podle me od vzdy.

    Pro priklad si uvedeme malou ukazku

    human readable format:

    [HTML Settings]
    AutomaticDetectionLanguage=3
    MediumFontSize=9
    MinimumFontSize=7

    human unreadable XML format:

    <!doctype fontconfig system "fonts.dtd">
    <!-- /etc/fonts/fonts.conf file to configure system font access -->
    <fontconfig>
    <match target="pattern">
    <test qual="any" name="family">
    <string>mono</string>
    </test>
    <edit name="family" mode="assign">
    <string>monospace</string>
    </edit>
    </match>
    </fontconfig>

    Samozrejme je to 'citelne' (to prectu), ale je to neprehledne jak prase.
  • 1. 7. 2008 10:42

    freshmouse (neregistrovaný)
    Proč mám dojem, že první ukázka kódu obsahuje méně informací než druhá? A proč to XML není zformátované tak, jak standardně bývá?
    <!doctype fontconfig system "fonts.dtd">
    <!-- /etc/fonts/fonts.conf file to configure system font access -->
    <fontconfig>
      <match target="pattern">
        <test qual="any" name="family">
          <string>mono</string>
        </test>
        <edit name="family" mode="assign">
          <string>monospace</string>
        </edit>
      </match>
    </fontconfig>
    
  • 1. 7. 2008 10:58

    Rejpal (neregistrovaný)

    O tolik méně toho zase neobsahuje. :-) Zrovna u fontconfigu si taky nejsem jistý, jaký má tahle šaškárna smysl. A zrovna u fontconfigu mi to docela vadí. ;/

  • 1. 7. 2008 11:18

    freshmouse (neregistrovaný)

    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. 7. 2008 11:57

    Rejpal (neregistrovaný)
    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).
  • 1. 7. 2008 12:25

    freshmouse (neregistrovaný)
    > 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. :-)
  • 1. 7. 2008 12:37

    freshmouse (neregistrovaný)
    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íň.
  • 1. 7. 2008 13:01

    Rejpal (neregistrovaný)
    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

  • 1. 7. 2008 13:38

    freshmouse (neregistrovaný)
    > 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é?
  • 1. 7. 2008 14:40

    Rejpal (neregistrovaný)
    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. :-)))
  • 1. 7. 2008 15:02

    freshmouse (neregistrovaný)
    > 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. :-)
  • 1. 7. 2008 18:47

    Daniel Kvasnička ml.
    Nechci se vtirat do vasi korespondence, panove :-) ...

    Jen k te HW narocnosti XML. Pri dnesnich cenach HW... pokud je proste nejaky vylozene dobry pripad pro XML (hodne document-centric IS apod.), tak nema smysl tohle resit... proste se za par supu koupi nejaka pamet navic a silnejsi procesor. XML a spriznene nastroje muzou byt na nektere ukony natolik dobre, ze nejaky cenovy narust z hlediska HW je pak relativne zanedbatelny.

    Napr. naprosto chapu, proc MarkLogic zvolil XML a XQuery pro svuj content server. Pro veci jako archivovani mailu napr. na markmail.org je to super reseni. A kdyby bylo XML tak zoufale pomale, asi by se ten jejich MarkLogic Server nepouzival v kokpitech letadel, kde piloti potrebujou s nekompromisni spolehlivosti ziskavat informace v radech sekund ;)
  • 1. 7. 2008 18:57

    Rejpal (neregistrovaný)
    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.
  • 1. 7. 2008 14:44

    Ondrej 'SanTiago' Zajicek (neregistrovaný)
    > 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.
  • 1. 7. 2008 15:10

    Ondrej 'SanTiago' Zajicek (neregistrovaný)
    Vypravela mi to osoba, ktera tam nejake nastroje implementovala. Ale za presnost me reprodukce nerucim.
  • 1. 7. 2008 14:53

    Rejpal (neregistrovaný)
    Jinak, vybavila se mi ta trefná poznámka: "Někteří lidé mají problém. Rozhodnou se nasadit XML. A najednou mají problémy dva." :-)
  • 1. 7. 2008 12:58

    Daniel Kvasnička ml.
    A ted mi ukaz, jak bys tim prvnim zpusobem zapsal ten druhy config. Na to jsem moc zvedavy. Nejen, ze jsi to nepredvedl na identickych datech, navic druha datova struktura je hierarchicka a prvni nikoliv.

    V pripade vCardu ti taky pripadne text lepsi nez XML? http://www.ibm.com/developerworks/xml/library/x-schematips/index.html?ca=drs-#N10127 (a jak tam budes nejakym modularnim zpusobem dostavat dalsi informace, kdyz tam neni nic jako namespaces?)
  • 1. 7. 2008 13:12

    Rejpal (neregistrovaný)
    A proč by ten druhý konfigurák měl psát zrovna tím prvním způsobem? Tím by se dostal z deště pod okap. :-) A vCard AFAIK podporuje extenze, aspoň podle Wikipedia. Sice na mě nějak nedělají dojem ta prázdná místa mezi středníky, v místech, kde zřejmě chybí hodnoty, ale jinak nevypadá tak špatně. :-)
  • 1. 7. 2008 13:18

    Daniel Kvasnička ml.
    IMHO ten textovy vCard je ukazkova prasarna :-) Prase aby to cetlo, prase aby to parsovalo. Kdyz to budu mnit v XML, staci mi libovolny XPath, XSLT nebo XQuery engine (nebo nejaky DOM, SAX ja nevim co) a muzu si s tim delat temer cokoliv.

    Bezhlave pouzivani XML na konfiguraky samozrejme je blbost. Ale tam, kde ty data vykazuji vyraznou hierarchicnost, je to IMHO nejlepsi reseni.
  • 1. 7. 2008 13:39

    Rejpal (neregistrovaný)
    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ě. :-)
  • 1. 7. 2008 14:32

    Daniel Kvasnička ml.
    Proc XQuery a JVM? libxml a libxslt ma dneska defaultne skoro kazda distribuce, nehlede na to, ze existuje uz napr. XPath 2.0 (~ skooooro XQuery) engine psany v cistem Pythonu. Ne vse kolem XML musi byt v Jave, i kdyz ta je na to vybavena nejlepe.
  • 1. 7. 2008 19:03

    Rejpal (neregistrovaný)
    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.)
  • 1. 7. 2008 11:40

    Rejpal (neregistrovaný)

    XML není ani čitelné, nečitelné. tedy pokud se bavíme o tom, jestli jsou čitelné specifikace od W3C, tak tom by skutečně dalo diskutovat. :-) Nicméně xml je metajazyk. co hodnotit dá, relativní čitelnost konkrétní aplikace XML vůči alternativám v konkrétním nasazení. A tam to je opravdu různorodé.

    Podle mého (neskromného :-)) mínění má XML největší smysl tam, kde se dřív používalo SGML - jako (rozšiřitelný) značkovací jazyk pro dokumenty (leckdy s opravdu bohatým schématem), kupříkladu jako DocBook nebo XHTML. Od toho se odvíjí spousta jeho vlastností, včetně možnosti rozšířit existující schéma tak, aby to aplikace mohla ignorovat a nenarušilo jí to zbytek, nebo vložit dokument v jednom schématu "inline" do dokumentu v jiném schématu.

    Nicméně spousta lidí začala cpát do XML věci, které v něm asi být nemusejí. Opět je nutné věci posuzovat porovnáním XML s alternativami. Třeba u takových věcí, jako je XML-RPC, má XML pořád ještě nějaký smysl: Elegantně se tak kupříkladu obejdou indiání v heterogenním prostředí, komunikující strany se nemusejí hádat o formát dat (na "nejnižší urovni"), a jak píše ESR, textový formát hezky leckdy člověka nutí vytvořit čistší rozhraní. Přesto jednak stále ještě existují binární komunikační formáty (výkon), jednak zrovna messaging asi nemá moc společného zrovna s čitelností - lidé to čtou poměrně málo, v podstatě by mohl vyhovět i jiný textový formát (přeci jen občas to někdo čte, třeba při ladění aplikace), ale proč znovuvynalézat kolo pro takový účel, jako je komunikace X desítek různých aplikací na Internetu? (I když některé jiné normy od W3C bych přijímal až po velmi zralém uvážení... ;-)

    Když ale vidím takové věci, jako konfigurační soubory, otázka "proč?" se myslím přímo nabízí. Tady je povětšinou producentem a konzumentem člověk (při editaci) a konzumentem software (po spuštění). Přitom na rozdíl třeba od DocBooku nejsou požadavky na brutálně flexibilní schéma, protože konfigurák nebude procházet X aplikacemi, dá se navrhnout "schéma" (spíš gramatika, že?) sice nerozšiřitelné bez zásahu do kódu aplikace, ale kompaktnější (proč je RelaxNG tak populární v RNC podobě, když všichni můžou používat i zobáčky?), navíc hladký text v konfiguračních souborech nezabírá (na rozdíl od dokumentů, kde text je "defaultní") takové procento textu, takže případná "těžkotonážnost" syntaxe hodně vystoupí na povrch. (Zrovna fontconfig je pěkný příklad.)

    A u takových věcí, jako je samotný základ systému, ani nevidím moc důvod zbytečně nabobtnávat kód XML knihovnou, leda, že bych chtěl uživatele od ruční editace úplně odradit. :-) Existuje-li aplikace, jejíž konfigurační soubory opravdu volají po XML, pak musím přiznat, že jsem na takovou zatím ještě opravdu nenarazil.

  • 1. 7. 2008 18:09

    Lael Ophir (neregistrovaný)
    Pokud jsem si všiml, tak je první problém v tom, že na unixech jste zvyklí používat editaci konfiguráku místo administrativního interface. GUI se na unixech píše špatně, je to spousta práce (zvláště když to má být dobré GUI), spousta serverů ani nemá grafický interface, a vůbec nějaké barvičky a ikonky... Potom je pochopitelně XML trochu problémem.

    Na druhé straně textové konfiguráky mají některé problémy navíc. Například mají více formátů. Když pak chce člověk změnit skriptem konfiguraci více kompoment, je to dost příšerné.

    Na a nakonec všechny konfiguráky (včetně XML) mají nevýhody. Například pomalé vyhledávání hodnot, velmi pomalé změny hodnot (je třeba přepsat celý soubor), nastávají problémy při vícenásobném přístupu ke stejnému konfiguráku... Neuvažovali jste si na unixech zařídit něco jako Windows Registry?
  • 1. 7. 2008 18:35

    Rejpal (neregistrovaný)
    Pokud jsem si všiml, tak je první problém v tom, že na unixech jste zvyklí používat editaci konfiguráku místo administrativního interface. GUI se na unixech píše špatně, je to spousta práce (zvláště když to má být dobré GUI), spousta serverů ani nemá grafický interface, a vůbec nějaké barvičky a ikonky... Potom je pochopitelně XML trochu problémem.
    XML má v tomhle směru problémy samo o sobě, zcela nezávisle na jakémkoli OS. Proto nechápu, jak to souvisí s Unixem. A YaST mi pořád ještě přijde bližší než Server Manager. Asi to bude otázka zvyku. :-) Ale ani u něj nechápu, co má společného s XML, protože ho pro většinu konfiguračních zásahů nepoužívá.
    Například pomalé vyhledávání hodnot
    Viz níže :-)
    Velmi pomalé změny hodnot (je třeba přepsat celý soubor)
    Myslíte, že Unix má problém s rychlostí zápisu desetikilového souboru?
    nastávají problémy při vícenásobném přístupu ke stejnému konfiguráku...
    Nenastávají, protože k němu nedochází. Copak konfigurace počítače je OLTP databáze?
    Neuvažovali jste si na unixech zařídit něco jako Windows Registry?
    A k čemu by to bylo? Statická data (typu "na jakém portu spustit na tomhle stroji webový server") klidně mohou být v textových souborech a dynamická data (přihlašovací údaje, konfigurace distribuovaných aplikací, centrální konfigurace cílů pro automatizovaný deployment Linuxu) jsou v LDAPu. Nevšiml jsem si, že by to Windows nějak extra jednotněji. Mám tu stroj s Windows Server 2008 a v něm vidím textovou konfiguraci, registr, LDAP databázi, databázi SAM... Neuvažovali jste na Windows, že si v tom taky uděláte pořádek? Jak dobře se v tom vyhledává? :-) Ten alarmismus je pěkný, a možná zmate nezkušeného uživatele, ale v tomhle směru není zcela opodstatněný.
  • 1. 7. 2008 20:28

    Lael Ophir (neregistrovaný)
    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).
  • 1. 7. 2008 11:49

    czeXit (neregistrovaný)
    jsem velky fanda Macu, ale na server bych si ho nedal - stejne jako bych tam nedal Windows.

    Linux je pro me "pruhledny", vim co se tam deje, co mam cekat a kde to hledat.
    Mac je naproti tomu slatanina opensource aplikaci a sw od Apple. Proto se napr. aplikace chovaji, tak jak se chovaji (jen nektere berou v uvahu /etc apod.)
    Nektere aplikace vyzaduji "admina", jine bez "roota" nebezi (ty opensourcove).
    Takze nakonec dopadnete se tremi administratory a do kazdeho druheho dialogu je postupne zkousite... : admin/root/diradmin...

    Mac na desktopy - rozhodne ANO, je to bomba - klikatka jako na windows a pritom lze sahnout "do vnitr" a mam unix. Stabilni, rychle, bez viru/spywaru.
    Na server ale ne, pokud mate trochu vetsi naroky nez si to jen naklikat ve wizardech konfiguraci, tak se z toho stane straslive tamagochi. Ne ze by to vadilo, to se casem stane lecjaky server, ale horsi je ze do nej poradne "nevidite" a Apple s necim takovym ani nepocital...
  • 1. 7. 2008 20:34

    Lael Ophir (neregistrovaný)
    Konkrétně s tím rootem a adminem je problém tak trochu na straně unixů, kde dlouhá léta měl řadu práv pouze uživatel root. To je samozřejmě špatný design. Všimněte si, že ve Windows máte všechny uživatele skupiny Administrstors rovnocenné, a user rights můžete přiřadit jak chcete (vyberete si skupiny a uživatele s právem provést shutdown, debugovat programy, založit page file atd).
  • 1. 7. 2008 21:25

    anonymní
    Člověk by skoro řekl, že některá ta oprávnění jsou trošku umělá. Oprávnění debugovat programy? To jako že pokud ve firmě jsou vývojáři, musejí speciální nastavení? Mimochodem, většinu těchhle věcí řeší geniální nástroj jménem sudo. Prakticky komukoli lze udělit velmi přesně definované akce, které smí provádět nad rámec toho, co by se dalo očekávat od běžného uživatele. Jinak Unix umí i skupiny, má-li někdo mít přístup ke zvukové kartě, stačí ho přidat do skupiny audio. Má-li někdo mít přístup k VirtualBoxu, stačí ho přidat do skupiny vboxusers. A takhle by se dalo pokračovat. Každopádně situace není tak strašná, jak se snad v každém příspěvku snažíte naznačit. Samozřejmě, mohla by být i lepší. Ale to se týká i Windows. :-) (Tím spíš, že místo mechanismů nabízejí jen zásady. Dají se ve Windows k těm existujícím oprávněním typu "může vypnout počítač" nějak konzistentně přidat další?)
  • 2. 7. 2008 10:33

    Lael Ophir (neregistrovaný)
    Oprávnění debugovat programy mají by default členové skupiny Administrators (nikoliv na tvrdo jeden uživatel root). Systém user rights je rozšiřitelný. Musel byste vytvořit nový securable object, definovat k němu odpovídající privilege, a LSA zařídí zbytek.

    Sudo řeší provádění příkazů, je to věc pro uživatele. Kdo nebo co říká, které účty smí použít to či ono API? Pokud jsem si všiml, tak se dnes již některé věci řeší v konfigurácích, existuje jistá rudimentální podpora něčeho typu priviledges.

    Samozřejmě sudo můžete triviálně implementovat i pro Windows, určitě byste základ napsal za víkend ;). Ale proč?
  • 2. 7. 2008 13:18

    Jiří Zárevúcky (neregistrovaný)
    "Oprávnění debugovat programy mají by default členové skupiny Administrators (nikoliv na tvrdo jeden uživatel root)."

    Hehe... tahle pasáž mě dostala. :) Odkdy je třeba k debugování programů nějaké speciální oprávnění? Normální vývojář přece při debugování v systému nehrabe, to je totální kravina. Já se nepovažuju za experta, ale programuju, a tenhle váš výrok mě málem shodil ze židle. Co přesně se skrývá pod tím oprávněním debugovat?
  • 3. 7. 2008 22:53

    Lael Ophir (neregistrovaný)
    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.
  • 2. 7. 2008 15:27

    Nene (neregistrovaný)
    Dle tretiho bodu by timto hodnocenim neprosel ani Solaris 10. Spousteni sluzeb pomoci SMF, ktery ma binarni repository s konfiguraci a zdroj pro tuto repository je v xml by totiz take neobstal :-)
  • 31. 7. 2008 12:34

    m (neregistrovaný)
    tie posledne 2 dovody su smiesne