Kam ten svět spěje...Linux už má (diskuse)

[Michal Marek (twofish)]

Chci vidět, jak uloží $SUBJECT do registry (jinak než do blobu)... Nemluvě o vimrc

Jinak Gnome 2 má taky něco jako registry, ale necpou tam konfiguraci Apache a podobné šílenosti.

[elviin]

Z dokumentace

klic:
user:aviram/env/env2/PATH: $PATH:~/bin:$JAVA_HOME/bin

A jak jsem cetl, tak budou ulozene ne-binarne, v xml. Je to moznost, tak proc to hned odsuzovat. Vzdycky se budou lidi snazit neco unifikovat a naopak hajit to, co je pestry - jako konfiguracni soubory;)

[Petr Mach]

Vis co je legracni? Ze ja na svem systemu zadne /etc/httpd/httpd.conf nemam, misto toho mam /etc/httpd/conf/httpd.conf, coz je jeden z problemu, ktery by mohla standardizace odstranit. Jinak je to konfigurak s klasickou stromovou hierarchii polozek, takze nevidim duvod proc by nemel jit prepsat do Elektry .

Konfiguracni soubory Vimu jsou ve skutecnosti skripty napsane v jazyku Vimu a jako takove jsou do staticke stromove struktury neprepsatelne. Pripad, kdy pouziti Elektry je nevhodne. Ale tvrdi tu snad nekdo, ze vsechno stavajici musi byt prepsano do Elektry? Vzdyt to je blbost, stejne jako je blbost, ze Windows vsechno cpou do registru.

A je snad duvod, ze Elektra neni vhodna uplne na vsechno, ji odmitnout i v pripadech, kdy naopak vhodna je? Imho neni. Imho jednotne (standardizovane) api pro praci s cfg. soubory je dobra vec a rada programatoru i systemovych administratoru by ji v rade pripadu privitala, proc jim tu moznost neposkytnout?

[Michal Marek (twofish)]

Jinak je to [httpd.conf] konfigurak s klasickou stromovou hierarchii polozek, takze nevidim duvod proc by nemel jit prepsat do Elektry .

Jak převedu do Elektry třeba tohle?

<Location /nejaky/adresar>
  order deny,allow
  deny from all
  allow from 192.168.1.0/24
  allow from 192.168.2.0/24
  Options jeden druhy treti
</Location>
 
 
<Location /jiny/adresar>
  order deny,allow
  deny from all
  allow from 192.168.1.0/24
  allow from 192.168.2.0/24
  Options jeden druhy treti ctvrty
</Location>

Nějak takhle?

Apache/
  ...
Apache/Location-9ea7093b4a90106c433d0d84ea438d6d/
  order="deny,allow"
  deny="all"
  allow-6aee88df6a1ebef84a61dede95ccf82a="192.168.1.0/24"
  allow-da143b176b284c4175f8eef5dc170f71="192.168.2.0/24"
  Options="jeden druhy treti"
Apache/Location-d12a6a1a840aa9a0e9ea955f1d2ae519/
  order="deny,allow"
  deny="all"
  allow-da143b176b284c4175f8eef5dc170f71="192.168.2.0/24"
  allow-da143b176b284c4175f8eef5dc170f71="192.168.2.0/24"
  ...

To skutečně výrazně zvyšuje čitelnost Taky to můžu zkusit takhle:

Apache/
  ...
  line930="<Location /nejaky/adresar>"
  line931="  order deny,allow"
  line932="  deny from all"
  line933="  allow from 192.168.1.0/24"
  line934="  allow from 192.168.2.0/24"
  line935="  Options jeden druhy treti"
  line936="</Location>"
  line937=""
  line938=""
  line939="<Location /jiny/adresar>"
  line940="  order deny,allow"
  line941="  deny from all"
  line942="  allow from 192.168.1.0/24"
  line943="  allow from 192.168.2.0/24"
  line944="  Options jeden druhy treti ctvrty"
  line945="</Location>"
  ...

Prostě u programu, jehož konfigurace je v nějakém jednoduchém regulárním jazyce typu proměnná=hodnota, # komentář, by asi nebyl problém použít Elektru, na druhou stranu pochybuju, že by se tím nějak usnadnil vývoj, protože a) naparsovat si takový konfigurák ručně je celkem trivka, b) knihoven co to umí je snad dostatek, c) to samé už dělá gconf.

Ale programy typu Apache by stejně potřebovaly nějaký vlastní formát, který do té Elektry uloží, takže unifikace veškerá žádná (resp. můžu k těm datům unifikovaně přistupovat, ale je mi to podobně platné, jako že můžu unifikovaně napsat fopen("/etc/foo", ...)). Viz ostatně Yetiho komentář o XML.

[Michal Marek (twofish)]

Navíc per-directory konfiguraci neukládá do registrů ani IIS (AFAIK), takže by Apache asi musel obsahovat jak parser té elektrifikované konfigurace, tak parser té old-fashioned konfigurace v .htaccess.

[Petr Mach]

Jeste to muzes zkusit teba takto:

<Location /nejaky/adresar>
  order deny,allow
  deny from all
  allow from 192.168.1.0/24
  allow from 192.168.2.0/24
  Options jeden druhy treti
</Location>

../Location/1/path="/nejaky/adresar"
../Location/1/order="deny,allow"
../Location/1/deny="from all"
../Location/1/allow/1="from 192.168.1.0/24"
../Location/1/allow/2="from 192.168.2.0/24"
../Location/1/Options="jeden druhy treti"

Pricemz seznam vsech locations by sis mohl nechat vypsat nejak takto:

kdb ls ../Location/*/path

ad a) tak mi predved ekvivalent

kdb set ../Location/1/allow/3/ "from 192.168.3.0/24"

ad b) viz ad a) a ukaz mi to pro ruzne konfiguraky, treba fstab a XF86Config

c) To dela, ale ten je zavisly na gnome, corbe, takze je tezko portabilni na jine systemy, oproti tomu Elektra nabizi mechanizmus wrapperu jak nad konfiguraci Gnome, tak i KDE.

Ne, prave o ze muzes ke vsem polozkam snadno a jednotne pristupovat lidsky i programove je platne hodne. Registry windows jsou nelidsky, stovky ruznych konfiguraku UNIXu jsou zase nepocitacovy.

[unchallenger]

kdb set ../Location/1/allow/3/ "from 192.168.3.0/24"

nemohu udělat jen tak. Tedy mohu, ale s nepředvídatelnými následky. Protože za normálních okolností musím vědět, čemu to allow nastavuji, proč nastavuji zrovna třetí allow...

V podstatě bude s kdb set vypadat konfigurování v nejlepším případě podobně, jako se dnes používá iptables. Je-li toto cílem...

[unchallenger]

Mimochodem, které prase nastavuje přístupová práva v Location a nikoli Directory?

[Petr Mach]

pan Michal Marek (twofish)

[Michal Marek (twofish)]

Njn, tak jsem to zkopíroval z nějakého example.

[Petr Mach]

Samozrejme, prave k tomu slouzi kdb ls. Je to nemlich stejne jako prace se soubory na prikazove radce. Ta je, div se tomu, take mozna .

[Michal Marek (twofish)]

../Location/1/path="/nejaky/adresar" [...]

To je jedno, jestli tam bude pořadové číslo nebo md5 součet, pořád tam musí být nějaká redundantní a nic neříkající hodnota, aby ty položky byly unikátní.

kdb ls ../Location/*/path

sed -n '/<Location[^>]*>/,/<\/Location>/p' httpd.conf

plus mínus.

kdb set ../Location/1/allow/3/ "from 192.168.3.0/24"

No a tohle mi je k čemu? Co je první Location a třetí allow?

[Petr Mach]

To neni plus minus vice mene stejne, protoze u me je to jednodussi a hlavne stejny mechanismus mohu pouzit u kterehokoli Elektrifikovaneho konfiguraku.

K cemu to je? Dobre to vis, nevyhybej se odpovedi. Tim z prikazove radky pridas/nastavis treti allow k prvni lokaci. Jak to udelas ty a ted?

[unchallenger]

A jak teď zafumfátoruji kuklímkvoš? K čemu se starat o to, jak něco udělat, když si nemyslíme, že to má smysl dělat nebo že to vůbec je dobře definovaná operace?

[Petr Mach]

Děkuji, za odpověď, myslím že už v tom teď máme všichni jasno, ne?

[unchallenger]

Podle tvé odpovědi asi ne.

Takže ještě jednou: Nástroj umožňující přidat cosi do třetí položky prvního čehosi je stejně užitečný jako sed, který mi umožňuje dopsat něco na n-tý řádek.

[Petr Mach]

Vyborne, takze mi predved ekvivalent napsaneho. Ukaz mi, jak sedem pridas polozku allow from 192.168.3.0/24 do Location /nejaky/adresar z prikazoveho radku.

Zjistis ze uzitecnost techto nastroju se diametralne lisi, sed ti to neumozni.

Ukaz mi to tedy jakymkoli jinym zpusobem. Myslim to vazne, predved mi, jak to udelas stejne snadno a nebo jeste snadneji, nez jsem to predvedl ja. Pak se muzem bavit o tom co je lepsi a co horsi. Jestlize nic takoveho predvest nedovedes, skutecne nema smysl se o tom bavit, je to jednoznacny.

A reci jako, ja snadne nastaveni cfg. souboru nepotrebuji, takze je unifikace pristupu k CFG souborum zbytecna, neberu. Dokud nenavrhnes lepsi reseni vyse uvedeneho problemu, je zbytecne protestovat a odsuzovat. Navrhni alternativu a muzeme se o ni pobavit.

[jm]

http://www.abclinuxu.cz/news/show/70303#79

[Petr Mach]

Doufam ze sis tam precetl:

Tím rozhodně netvrdím, že httpd.conf se dá krásně upravovat sedem (nedá)

Je to totiz nespolehlive a prakticky si tohle nemuzes dovolit pouzit, nemuzes zarucit, ze to u vsech udela to same. Co kdyz to bude zakomentovane? Pak pridas do toho konfiguraku nesmyslny radek. Nebo co kdyz te ted postavim pred problem tu polozku naopak smazat? Nebo ji zakomentovat ci ji okomentovat?

V Elektre tohle vsechno jde a spolehlive. A to se bavime o jednom cfg. souboru, co kdybych te postavil pred jiny, co treba v XF86Config u Screen1 odstranit mod "1152x864"?

Uz chapes?

[jm]

V Elektre tohle vsechno jde a spolehlive. A to se bavime o jednom cfg. souboru, co kdybych te postavil pred jiny, co treba v XF86Config u Screen1 odstranit mod "1152x864"?

Ano, Elektra spasi svet. Mimochodem, urcite za me taky nakonfiguruje sendmail, nebo snad ne? Ja opravdu nepotrebuji skriptem odstranit nejaky mod z konfiguraku Xek. Ja si to upravim rucne nebo si spustim nektery z mnoha nastroju, ktery je pro tento ucel napsan. Urcite ne Elektru, ktera vubec nevi, co dela, krome toho, ze prepisuje casti konfiguraku pomoci hodnoty nejakeho klice. On ten nastroj, ktery je k tomu urcen, totiz mj. zajisti takovou drobnost - napise to syntakticky spravne.

[Petr Mach]

Ano, Elektra spasi svet. To je tve tvrzeni .

Me tvrzeni je, ze Elektra muze rade vyvojaru i adminu usetrit praci a starosti, tudiz by mela dostat sanci.

Co potrebujes ty je mi vcelku jedno. Rucni uprava neni automaticka a tu radu nastroju musela napsat rada lidi a tato rada lidi by prave uvitala, kdyby to slo udelat snadno .

Urcite ne Elektru, ktera vubec nevi, co dela Vsak to taky neni jeji ucel . Po pate te odkazuji, precti si dokument o tom, co odmitas, vsechno toto se tam pise a vysvetluje. Elektra NENI JEDEN Z RADY GUI KONFIGURACNICH NASTROJU JAKO JE YAST NEBO DRAKCONF. JEJI UCEL A SMYSL JE JINY? JEJI SMYSL A UCEL JE UNIFIKOVAT PRISTUP KE KONFIGURACNIM SOUBORUM. Kdyz ti to napisu takhle, budes si to konecne pamatovat? Prinos elektry je prave v tom, ze ti, mimo jine, snadno umozni vytvaret GUI nastroje jako YAST. Ted to totiz snadne neni.

[jm]

Ja zadny unifikovany pristup nepotrebuju, GUI konfiguracni nastroje me nezajimaji a nedejboze, aby tyto nastroje mohl snadno vytvaret kdejaky matla nejlepe jeste v GUI vyvojovem prostredi bez pochopeni syntaxe prislusnych konfiguracnich souboru.

[Petr Mach]

Na svete nastesti nejsi jenom ty .

[Michal Marek (twofish)]

Nevšiml jsem si toho path, potom by mi stačilo třeba grep '<Location'

Ad ../Location/1/allow/3/ -- potřebuju ale vědět, že první Location je přesně to co chci, to znamená, že jsem si ji tam předtím sám (ten samý program) přidal, jinak tam může být bůhvíco. Se současným httpd.conf bych mohl machrovat, že můžu přidat direktivu přesně na 137. řádek:

sed -i '137aLoadModule ...' httpd.conf

, ale taky je mi to platné jak mrtvému cvičky pokud se v tom httpd.conf hrabal někdo jiný.

Přidat allow k nějaké konkrétní Location by snad šlo zautomatizovat takhle

sed -i '/<Location cesta>/aallow from 1.2.3.4' httpd.conf

Tím rozhodně netvrdím, že httpd.conf se dá krásně upravovat sedem (nedá), ale Elektra to o moc líp neřeší (kromě toho, že je potřeba ohnout syntax, aby šla do Elektry vůbec uložit).

[Petr Mach]

Vedet ze Location ktera me zajima je zrovna ta prvni nebudu, ale pomoci ls to lze to snadno zjistit.

Treba

kdb ls ../Location/*/path  #seznam vsech location
kdb ls ../Location/1/allow/* #seznam vsech klicu allow

Kbd by take mohl poskytovat nejaky dotazovaci nastroj, ktery by mi vratil rovnou to cislo, treba zalozeny na standardnim XPath. Nevim jestli neco takoveho nabizi. I kdyby ne a ta potreba se ukazala, tak neni problem takovy nastroj vytvorit. To uz jsou detaily. Vyznamna je nosna myslenka, unifikovany pristup k cfg. souborum, kdy neni kazda ves jiny pes. S jednotnymi cfg. soubory se da snadno pracovat, a nastroje pro ne vytvorene budou univerzalni, stejne jako je to ve svete XML.

kromě toho, že je potřeba ohnout syntax, aby šla do Elektry vůbec uložit Ano, to je pravda, ve skutecnosti by to chtelo cele prekopat jeste vic, aby to bylo schopno lepe vyuzit moznosti ktera hierarchicke ukaladni klicu nabizi. Ale vadi to snad necemu?

[jm]

kromě toho, že je potřeba ohnout syntax, aby šla do Elektry vůbec uložit Ano, to je pravda, ve skutecnosti by to chtelo cele prekopat jeste vic, aby to bylo schopno lepe vyuzit moznosti ktera hierarchicke ukaladni klicu nabizi. Ale vadi to snad necemu?

Ano, jak vidite, tak to nesmirne vadi mnoha uzivatelum a vyvojarum. Ale to jenom takovy drobny detail.

[Petr Mach]

Jestli to vadi vyvojarum, reseni je snadne, Elektru nebudou pouzivat.

A uzivatele? Nevidim ze by to vadilo mnoha uzivatelum. A naopak, rade uzivatelu a administratoru zase nesmirne vadi, ze konfigurace cehokoli je obtizne proveditelna. Co ted s tim? Kdo dostane prednost?

V mem pripde pro to vadeni je realny a zavazny duvod, Elektra nebo neco podobneho jeste lepsiho, by jim usnadnila zivot a usetrila praci. Jaky duvod pro to vadeni je v tvem pripade? Tj. proc to vadi?

[jm]

A uzivatele? Nevidim ze by to vadilo mnoha uzivatelum. A naopak, rade uzivatelu a administratoru zase nesmirne vadi, ze konfigurace cehokoli je obtizne proveditelna. Co ted s tim? Kdo dostane prednost?

Ne? Ja naopak vidim v teto diskusi vetsinu uzivatelu, kterym to vadi a to tak, ze velmi. Linux jsem neinstaloval proto, abych se postupne dostal zpatky do situace, v jake jsem byl pod Windows. S pomoci projektu typu Kinux, Gnome a Elektra tam ale bohuzel zrejme speje.

[Petr Mach]

Aha, to jsou jestli dobre pocitam tri z nekolika milionu? ) A co uzivatele, kteri by linux pouzivali, kdyby se dal snadno konfigurovat, a protoze se neda, tak ho nepouzivaji, tys take zapocital?

Do situace jako byla pod Windows se nedostanes. Gnome ani Elektra neni to same. O tom ze netusis co to Elektra vlastne je a k cemu slouzi tu podavas presvedcive dukazy, to same se bude pravdepodobne tykat i Gnome. Co se tyce KDE, tak tam jsi se, pravdepodobne nahodou, trefil. Ale nikdo te prece nenuti ho pouzivat.

Ale schvalne, co spatneho z Windows by ti Elektra prinesla?

[jm]

Konfiguracni soubory Gnome jsou stejny paskvil, jako Elektra, aneb pokrocily syndrom posedlosti XML. O "kvalitach" Gnome ostatne spolehlive vypovida to, co se stane, kdyz si Gnome aplikace zkusite spustit nekde jinde, nez pod Gnome.

Uprimne receno, pokud by prisun dalsich uzivatelu znamenal zmeny systemy v tomto duchu, tak me takovi uzivatele naprosto nezajimaji. Az tady budeme mit druhe Windows s jednotnym unifikovanym regeditem, tak uz konecne spolu s vyvojari Elektry budete spokojen?

[Petr Mach]

Konfiguracni system Gnome neni tak dobry, jako nabizi Elektra.

Ja se spoustenim Gnome aplikaci pod negnome nemam problemy.

Az tady budeme mit druhe Windows s jednotnym unifikovanym regeditem, tak uz konecne spolu s vyvojari Elektry budete spokojen? Nebudu, windows a jejich registry jsou shit. Elektra je o necem jinem. Az tu bude jednotny pristup ke konfiguracnim souborum mozny z prik. radku, vcetne nastaveni, tak opravdu budu spokojen.

[Petr Mach]

Mimochodem, XML je vyborna technologie, ktera ma radu vyhod a proto je tak uspesna, a to i navzdory skarohlidum, kteri to nechapou.

[jm]

Samozrejme. A proto je treba odpurce asimilovat a hlavne aplikovat tuto technologii i tam, kam se naprosto nehodi. A vytvorit desitky dalsich "standardnich" rozsireni, to je to prave orechove...

Cesta do pekel byva dlazdena dobrymi umysly.

[Petr Mach]

Ten odpurce jsi ty a nekdo te chce asimilovat? Rekni kdo, ja si to s nim vyridim.

Ale nedopoustis se ty toho sameho vuci Elektre? Proc se branis jejimu zavedeni jako standardni soucasti linuxu, jeji pouzivani nebude povinne, a rada vyvojaru to uvita, protoze Elektra prinasi novou kvalitu prace s cfg. soubory, to je nezpochybnitelny fakt.

[VícNežNic]

Nebude povinné? S tím bych nesouhlasil. V případě přijetí Elektry většinou vývojářů se bez ní, obávám se, nikdo neobejde.

Já jsem taky velký odpůrce Elektry, protože vymyslet jméno, které se mi tak šíleně nelíbí jako právě Elektra, to muselo dát sakra práci.

[Petr Mach]

Ne, pouzivani Elektry nebude a ani nemuze byt povinne, neexistuje nikdo, kdo by tuto povinnost mohl naridit. Jestlize se ale vyvojari sami rozhodnou vetsinove ji pouzivat, dobrovolne podotykam, pak na ni asi neco bude, ne?

Byt odpurce elektry, protoze se mi nelibi jeji nazev je iracionalni, netechnicke, nelinuxove. Takto se muze rozhdovat zenska o barve svych vlasu, ne vzdelany clovek o pouzivani nejake knihovny.

[VícNežNic]

No… Nepoužívat něco kvůli názvu je sice možná iracionální, netechnické a nelinuxové (nedělám si nijak velké ambice být čímkoliv z toho), nicméně pro mě je to důležité vodítko. Pokud není vývojář schopen zvolit vhodný a vkusný název pro svůj program, nebo si ho nechat poradit, mám mu dát tolik důvěry a používat ho?

Tvrdit, že nemít něco rád kvůli názvu je iracionální, netechnické a nelinuxové je sice možná racionální, technické a linuxové, ale takto může nějaký technik vybírat odpory z přihrádky, ne argumentovat v bouřlivé diskuzi.

Každopádně narozdíl od vás jsem přišel s argumentem, jehož pravdivost nedokážete popřít! Zkuste mě přesvědčit, že se mi to jméno líbí :-P

[jm]

Viz tento vas prispevek.

Idealni stav je, aby byla Elektra zakladni knihovnou jako treba glibc nebo primo jeho soucasti...

Ano, opravdu se branim tomu, aby se neco podobneho cpalo do glibc nebo na uroven teto knihovny, protoze to pak pujde opravdu velmi obtizne vypnout, ze... Pod "novou kvalitou" si patrne kazdy predstavujeme neco jineho; ja napr. rozsekani konfiguracnich souboru do spicatych zavorek za zadnou novou kvalitu nepovazuji.

[Petr Mach]

To je idelani stav, ktery jak znamo neexistuje.

Vis co, ja jsem se prave rozhodl, ze se mi nelibi knihovna libpcre, muzes mi poradit, jak ji mam vypnout?

ja napr. rozsekani konfiguracnich souboru do spicatych zavorek za zadnou novou kvalitu nepovazuji.

To ja take ne, ale zato si pod tim predstavuji moznost pracovat snadno to jest spolehlive, jednotne a bez velke namahy s cfg. soubory z prikazove radky, ve skriptech a nebo treba v Pythonu a to jak u vlastnich, tak i cizich programu.

Dalsi kvalitou, kterou Elektra prinasi je moznost nastavit opravneni ke kazdemu klici jako k souboru.

[jm]

Dalsi kvalitou, kterou Elektra prinasi je moznost nastavit opravneni ke kazdemu klici jako k souboru.

Hura, konecne to bude presne jako ve Windows!!!

Akorat to ma jeden drobny zadrhel - aplikace bude muset cist primo ty elektrokonfiguraky. Cili jste se konecne priznal k tomu, ze konecnym cilem je proste vyhladit stavajici konfiguracni soubory. Diky, nechci!!!

[Petr Mach]

Ne, nebude to jako ve Windows, bude to lepsi nez ve Windows .

Ja jsem se konecne priznal? ) Nejsi paranoidni? Po seste te odkazuji, precti si ten dokument o kterem diskutujeme, tohle vsechno je tam naprosto jasne a srozumitelne uvedeno.

A znova, co ty chces nebo ne je irelevantni. Jestli jsi programator, nikdo te nenuti Elektru ve svych programech pouzivat, ale nebran v tom ostatnim programatorum, jako ostatni programatori nenuti tebe Elektru implementovat.

[jm]

Ne, nebude to jako ve Windows, bude to lepsi nez ve Windows .

Hura, uz aby to bylo! Prava k souborum jsou prezitek, potrebujeme prava ke klicum. Doufam, ze uz ma Linus zaregistrovanu ochrannou znamku Kinux, bude to jiste trhak.

[Petr Mach]

Jestli si myslis ze jsi vtipny, tak nejsi, jen ukazujes, ze ti schazi skutecne argumenty.

Prava k souborum nejsou prezitek, ale mit stejna prava i ke klicum je vhodny doplnek, maji stejny smysl jako prava k souborum, jejich vyznam doufam popirat nechces.

[jm]

Zadna prava ke klicum nikdo nepotreboval, dokud se neobjevila Elektra. Nikde jsem si nevsiml, ze by nekdo volal, dejte nam prava ke klicum v registrech. Smysl toho je jaky? Aby si uzivatel mohl upravit jenom cast konfigurace? Aha, uzivatelske konfiguraky ~/.neco uz jsou patrne s Elektrou taky prezitek, jak vidim. To je ale pokrok...

No, podarilo se vam nacrtnout skoro dokonalou koncepci, jak z Linuxu udelat Windows, jenom mi tak nejak schazi smysl tohoto pocinani - Windows uz existuji. Mimochodem, to by me vazne zajimalo, jak chcete osetrit prava ke klicum ve vztahu k pravum k danemu elektrakonfiguraku. Patrne modprobe elektra && chmod a+E. Bezva myslenka.

[Petr Mach]

Tvuj problem je, ze jsi namysleny hlupak, ktery ma snahu mluvit za ostatni.

Jak vis ze to nikdo nepotreboval? A kde jsi prisel na to, ze ~/.neco je prezitek? Vymyslis hlouposti a pak proti nim protestujes.

Jenze rizeny pristup ke klicum v cfg. souboru je uzitecna vec a obcas se hodi. Prave nemoznost ridit pristup ke klicum vedlo pred par lety k zavedeni /etc/shadow. Ale /etc/shadow je obezlicka, neni to systemove reseni a neni pouzitelne vsude.

Rizeni pristupu k jednotlivym klicum by se hodilo napr. i u /etc/fstab, bylo by fajn, kdyby si uzivatele _nektere_ vlastnosti u _nekterych_ mountpointu mohli nastavit sami.

Mimochodem, jak hodlas se svym ~/.neco hodlas zaridit, ze polozky a, b, c mohou nastavit vsichni uzivatele, d, e, f jenom Karel, Martin a root, zbytek jen root? Dejme tomu v XF86Config?

S Windows a jejich koncepci to nema nic spolecneho. Mas z windows fobii, jakmila mas pocit ze je to o nich, tak panikaris, zatemnuje se ti mysleni a ztracis soudnost. Jestli si myslis ze linux je genialne navrzen a nema sva slaba mista a nedostatky, tak jsi blbec. A jestli si to nemyslis, tak bys mel videt, ze zrovna tezce roztristene konfiguracni soubory jsou jednou z jeho nejvetsich slabin, ktera zabranuje delat treti strane efektivne ruzne konfiguracni nastroje, hromadne menit konfiguraci na pocitacich v siti, ridit jemne pristup ke konfiguracnim polozkam a tak dale a tak dale.

A mimochodem, i ve Windows jsou nektere veci resene lip nez v linuxu a neni nic spatneho se na jejich reseni poucit. MS obslehava linux a UNIXy zrovna tak. Treba .NET je jasny pripad obslehnuti osvedcenych UNIXovych reseni, zavedl zde jak jednotlive cfg. soubory (opustil registry, ale zachoval jednotny pristup a api k nim, tedy je to obdoba toho reseni, co nabizi Elektra), tak treba verzovani knihoven s tim, ze v ceste se objevuje verze knihovny, takze jich lze instalovat systemove soucasne vice najednou, cimz konecne vyresi svuj odveky problem - dll hell - coz prispeje k lepsi stabilite win (.NET) programu.

Pokud MS bude vyuzivat a brat si pouceni z toho, co linux resi lepe, treba technologii lokalizace sw. kde dnes tezce zaostava a podobne a linuxova komunita bude zatvrzele trvat na sice blbem, ale svem reseni, to jest nebude ochotna se nechat poucit lepsim resenim, tak se Windows z podstaty veci stanou lepsim systemem, protoze to bude souhrn tech nejlepsich technologii a reseni.

Takze uklidni nervy a vem rozum do hrsti a zkus z nej neco vymacknout, OK?

[jm]

Rizeni pristupu k jednotlivym klicum by se hodilo napr. i u /etc/fstab, bylo by fajn, kdyby si uzivatele _nektere_ vlastnosti u _nekterych_ mountpointu mohli nastavit sami.

Mimochodem, jak hodlas se svym ~/.neco hodlas zaridit, ze polozky a, b, c mohou nastavit vsichni uzivatele, d, e, f jenom Karel, Martin a root, zbytek jen root? Dejme tomu v XF86Config?

Ad 1/ Jejda. A nemeli by si nahodou uzivatele tyhle veci mountovat v userspace a necpat se do /etc/fstab?

Ad 2/ Klid, Xka uz stihli lidi od Elektry zprznit, muzete si je rychle opatchovat a honem to nainstalujte!

Jinak Kinux jiz vas problem taky taky vyresil a to bez svete div se bez Elektry.

[Petr Mach]

1) Tezko, uzivatele na to nemaji by default pravo, a rizeni pristupu, tj. kdo a na co pravo ma, je hrube a nedostatecne. Takovou zakladni vec bys uz mohl vedet.

2) Ano, takze resenim je pouzit Elektru, nebo podobne reseni. Tady vidis, ze tradicni cfg. soubory maji sve nedostatky, ktere je nutno nejak obchazet. Reseni KDE je zavisle na KDE, coz neni zrovna to prave. Chtelo by to nejake systemove reseni, Elektra by mohla byt timto systemovym resenim. Jsem rad, ze jsi pochopil, jak se veci maji.

[jm]

Ad 1/ Ale no tak: Napr. http://ivman.sourceforge.net/wiki/tiki-index.php

Ad 2/ Ne, nepochopil, resp. rozhodne ne tak, jak byste si asi myslel nebo pral.

[Leoš Literák]

Prava k souborum jsou prezitek, potrebujeme prava ke klicum.

Uprimne receno, zakladni sada uzivatelskych prav k Linuxu (rwx, ugo) je velmi nedostatecna a zastarala. Kdyz to porovnam s Novellem trojkou, co jsme meli na univerzite pred lety, tak to bylo dost slabe. Na svazcich Novellu jsem si mohl napriklad vytvaret vlastni skupiny uzivatelu, kteri meli/nemeli pravo urcite akce na dany soubor ci adresar.

Uz je to davno, od te doby jsem Novell nevidel a tudiz vetsinu pozapomnel, ale ze vyjadrovaci sila jeho pristupovych prav jasne prevysovala Unixy, to si pamatuji.

PS. vim ze v Linuxu je mozne krome bezneho chmod pouzivat nejake dalsi zpusoby rizeni pristupu, ale ani si nepamatuji, jak se jmenuji.

[jm]

Jmenuje se to ACL a plne mi to dostacuje, spis bych rekl, ze to je komplexnejsi, nez by bylo nutne.

[Petr Mach]

Nevadi ti, ze ACL pouzival driv Microsoft a je to nativni soucasti a koncepci Windows?

[jm]

Ale no tak, to je vazne trapny pokus... POSIX ACL != Windows ACL

[Petr Mach]

Implementacne ne, ale koncepcne ano. Ukazalo se, ze koncepce tradicnich unixvych prav je nedostatecna, tudiz jsme se podivali jak to resi konkurence a ejhle, jsme i nadale konkurenceschopni.

A tak jako je to v poradku pristupovych prav, taj je to v poradku i v jinych oblastech, bez ohledu na to, ze to MS obslehnul driv nez Linux.

[jm]

No, tohle vazne nema smysl, to jste fakt me pobavil. Vite co, zkuste zapatrat po Googlu (hint: IEEE 1003.1e). V te dobe se mozna Gatesovi zdalo o Windows 1.0

Nicmene jsme silne OT. Jinak uzitecnost ACLs a jakesi nesmyslne parodie na MS registry je naprosto nesrovnatelna.

[Michal Marek (twofish)]

Ano, to je pravda, ve skutecnosti by to chtelo cele prekopat jeste vic

<ionie>Ano, ono by to šlo překopat i tak, aby se httpd.conf dal uložit do relační databáze, a unifikovaně přistupovat k ní</ironie>

Co by chtělo překopat je Elektra, aby vůbec byla schopná ukládat konfiguraci v nějaké složitější gramatice, jinak bude za chvíli potřeba nějak unifikovat různé hacky jak do Elektry uložit informaci o typu, víc položek stejného jména etc... Osobně bych to překopání viděl na

ln -sf libxml.so /usr/lib/libkdb.so
rm -f /lib/libkdb.so

Prostě a jednoduše proto, že jeden všespasitelný formát už tu máme a narozdíl od Elektry dokáže uložit i konfiguraci Apache (a nějak rozumně s ní pracovat). Problém je v tom, že má často docela velký overhead, takže v případě Apache bych to viděl na konfigurák v XML plus XSLT transformaci (která by nemusela být zas tak složitá) do původního konfiguráku -- kdo by nechtěl používat konfigurační nástroje, smazal by XML konfigurák a pracoval by s tím normálním. Tohle si můžou u SUSE napsat, aniž by nějak museli hackovat Apache (*).

U xorg.conf/XF86Config bych si i dovedl představit samotný konfigurák v XML, koneckonců ten současný nemá k XML moc daleko.

(*) Myšlenka "konfigurák generující konfigurák" není nijak původní, takže by to snad moc nevole nevyvolalo, pokud by to šlo nějak jednoduše vypnout

[Michal Kubeček]

Ad (*): hlavně to tak SuSE (a nejen SuSE) v mnoha případech už dávno dělá. Nevoli to vyvolává, ale pokud jsem si všiml, jen u těch, kteří SuSE ze zásady nepoužívají - kdo ano, ten si to prostě vypne (vadí-li mu to), stejně jako splashscreen při bootu, SuSEwatcher apod.

[Alex]

Myslím že čas prokázal, že způsob uložení konfigurací resp. konfig. souborů v *nixech je dostačující a efektivní a aniž bych autorovi Elektry chtěl přát něco špatného, myslím že se to neuchytí

Co udělali v GNOME (gconf) se mi také moc nelíbí, ale alespoň je to pouze pro desktop a integrované aplikace a navíc je to uložené pěkně v samostatných XML souborech.

[Lukas]

jasne, jedine souhlasim, nejak jsem nepochopil k cemu to cele je??? ono nestaci system unix conf souboru. /etc/ ??? Zatim jsem nepocitil potrebu mit takovy paskvil na linuxu. To ze s tim musim bojovat na windows mi uplne stacit, proc si tedy k*rvit linux. doafam,ze to skonci v propadlisti dejin...

[Petr Mach]

Staci to, ale ma to sva slaba mista, ktera elektra resi.

Elektra s hruznymi registry windows ma pramalo spolecneho . Elektra nejsou registry, ale snaha o standardizaci api pro praci s cfg. soubory. A je snad na standardizaci api neco spatneho? Proc?

[jm]

Standardizace? To jako ze bambilion konfiguracnich souboru v ruznem formatu preparsuju do jednoho obludneho registru, odkud si je budou cist jine aplikace - to ma byt standardizace?! Bezva.

[Petr Mach]

Clovece, jestli o tom chces diskutovat, tak si o tom nejdriv neco precti . O zadny obludny registr se nejedna. Naopak, jednotlive cfg. zustanou zachovany a nejen to, pujdou nstavovat snadno i z prik. radku, treba ve skriptech, coz je ted docela problem zaridit.

[jm]

Jasne, zustanou zachovany - v registru. Vite co? Bezte mi s tou hovadinou k sipku! Snadno si je nastavim i ted, a zadnou Elektru k tomu nepotrebuju.

[Michal Kubeček]

Pokud se hodláte pokaždé, když vám dojdou argumenty, uchýlit k prázdným posměškům a vulgaritám, bude lépe, když reagovat nebudete.

[jm]

Pardon, ale ja pro tento vymysl jine nez vulgarni oznaceni bohuzel nenechazim - a to se jeste celou dobu snazim mirnit... Nevim, co v tom vidite vy za zazrak.

[Michal Kubeček]

Nevidím v tom zázrak, ani nevím, zda mne to oslovuje. Ale pokud se mi něco nelíbí, napíšu, co se mi na tom konkrétně nelíbí. Nesnížím se k tomu, abych trousil trapné posměšky a rozhazoval nadávky. Tím bych totiž ve skutečnosti nevystavoval negativní hodnocení tomu projektu, ale jen a jen sobě. Ale vám to zřejmě nevadí...

[jm]

Co se mi na tom nelibi? Vsechno! Je to naprosto bezcenna <>vina, nevim co k tomuhle pokladu dal rict. Muzu tady vyjmenovat desitky potrebnejsich zalezitosti, ale asi je to zbytecne. Nekde holt ma nutkavou potrebu sjednotit "narod"...

[Michal Kubeček]

Děkuji. Aspoň teď mám jistotu, že mé tušení bylo správné. Argument nemáte žádný, jen emocionální averzi. Pokud tedy za argument nepočítám to, co jsem popsal dnes v 00:42...

[Petr Mach]

Jiz jsem rekl, ze se o zadny registr nejedna, fakt si o tom nejdriv neco precti, kdyz to chces odsuzovat.

Jak z prik. radku (skriptu) snadno nastavis polozku v /etc/fstab, XF86Config a nebo treba httpd.conf? Zrejme jsem se linux spatne naucil, protoze ja neco takoveho neumim.

Elektra by tohle umoznila, v rade pripadu by to imho melo znacny prinos, ne?

[jm]

Jiz jsem rekl, ze se o zadny registr nejedna, fakt si o tom nejdriv neco precti, kdyz to chces odsuzovat.

Jak z prik. radku (skriptu) snadno nastavis polozku v /etc/fstab, XF86Config a nebo treba httpd.conf? Zrejme jsem se linux spatne naucil, protoze ja neco takoveho neumim.

Napr. jiz zminovany sed, perl, dokonce existuje nekolik PHP aplikaci pro spravu webhostingu, ktere s httpd.conf zcela bezne pracuji. A to, ze httpd.conf rozsekam a narvu kolem jeho casti mraky spicatych zavorek a dalsiho balastu navic, mi praci rozhodne nezjednodusi.

[Petr Mach]

Ano, je to hodne exponovany konfigurak (pouziva se navic i ve windows, kde lide na primou editaci nejsou zvykli a prijde jim slozita), takze lidem stalo za to napsat specialni programy. Ale plati to o vsech konfiguracich? Neplati, a proc? Protoze ne vsechny jsou takto exponovane a protoze nemaji unifikovany pristup, je to moc pracne, aby se tim nekdo zabyval. Elektra to usnadnuje a krome toho k tomu nabizi univerzalni GUI editor i univerzalni nastroj pouzitelny z prik. radky (tj. ve skriptech).

Pres vsechny ty programy porad trva otazka, jak to udelas z prik. radku? Predved mi to prosim. Jestli neumis nebo se ti pro prilisnou pracnost nechce, tak uz vis v cem je prinos Elektry.

Jinak jsi psal, ze se ti na Elektre nelibi vubec nic. Proc se ti nelibi, ze umoznuje snadno nastavovat konfiguraky ze skriptu a prikazove radky?

Proc se ti nelibi, ze je lehka a krome glibc na nicem nezavisla, takze velmi snadno portovatelna?

Odpovez prosim.

[unchallenger]

Nemáš pravdu, že umožňuje něco nastavovat z příkazové řádky, aniž projdu celou strukturu a zjistím, co vlastně kam nastavit. Nástroj si může spokojeně umožňovat tucet oprací, které k ničemu nejsou, a smysl mu to nedá.

[Petr Mach]

Nikde nic takoveho jako aniž projdu celou strukturu a zjistím, co vlastně kam nastavit netvrdim.

Ale u jednoznacnych nastaveni, coz neni pripad httpd.conf, je mozne i toto.

[jm]

Eh, motame se stale dokola. Jak zajistim synchronizaci mezi konfiguracnimi soubory v /etc a v nejakych registrech? Kdo to naprogramuje? Vyvojari Apache, MySQL, ... (dopln si sam) to rozhodne nebudou, nevim proc by to delali. Takze to udelaji vyvojari Elektry? A ja si teda necham sahat do konfigurace systemovych sluzeb nejakym regeditem? No to uz snad muzu rovnou pouzit YaST, DrakConf, atd. (dopln nazev distribucniho klikadla przniciho konfiguracni soubory), nemusim vymyslet jeste neco dalsiho. Nebo klasicke konfiguracni soubory zrusime (coz je patrne sen vyvojaru Elektry)? Dekuji, nechci.

A hlavne - nejdriv musim vedet, co do tech konfiguracnich souboru chci zapsat, pak muzu resit, jak to udelat. A bud mam potrebu to skriptovat (a pak si nejaky skript napisu nebo najdu na webu) nebo tu potrebu nemam, protoze je to treba prilis pracne a prinos neodpovida vynalozenu usili, pak proste ty soubory upravim interaktivne z prikazove radky. Ne, nepotrebuju skript na upravu /etc/fstab, protoze ten soubor upravuju asi tak jednou za uhersky rok. Stejne jako nepotrebuju skripty na upravu spousty dalsich veci. Elektra se snazi buhviproc ze vsech konfiguracnich souboru XML. Kdyby XML bylo tak uzasna vec, tak by na nej asi vyvojari presli sami, ne? Jelikoz se tak nestalo, tak to asi za tak uzasnou vec nepovazuji. Pokud nebudu vedet, co do tech konfiguracnich souboru napsat, tak mi nepomuzou ani vsichni svati, natoz nejaka Elektra se svymi spicatymi zavorkami.

[Petr Mach]

V jakych registrech? Jiz dvakrat jsem ti rekl, ze zadne registry ala windows elektra nezavadi.

Naprogramuje to ten, kdo o to bude stat. Ja tu prece nechci nic jineho, nez moznost volby. Nemluv za vyvojare Apache, MySQL a dalsich, nevis zda by to uvitali a nebo ne.

Nikdo te regedit nutit pouzivat nebude. Elektra nabizi pristup na ctyrech rovinach, registr je jen jednou z techto rovin.

Jasne ze muzes pouzit YaST nebo DrakConf. Elektra s timto nema nic spolecneho, po treti te vyzyvam, precti si ten dokument o kterem diskutujem, tohle vsechno se tam totiz pise .

Sen vyvojaru elektru je unifikovany pristup ke konfiguraci. To ze nechces ty nic neznamena, nejsi stred vesmiru. Nekteri chteji, jini ne. Proto rikam, vytvorme rovnou moznost volby. Kdyby o to nestal nikdo, nemas se ceho bat. Ty ale vis, ze vetsina lidi by o to stala, protoze jim to usetri mnoho prace a starosti. Proto se branis i vytvoreni te moznosti volby.

To co potrebujes ty je irelevantni, mam snad kricet, ja nepotrebuju SMP, tak ho proboha nedelejte, je zbytecny, k nicemu, je spatny, fuj, bleee, pryc s nim? ) To je iracionalni chovani.

Elektra se nesnazi udelat ze vsech cfg. souboru XML, Elektra se snazi nabidnout unifikovany pristup ke konfiguracnim souboru, jestli je uklada do do XML, BFML nebo jinam je vedlejsi. Ze zvolili XML je proto, ze XML je standardizovany format, coz ma dalsi radu vyhod.

Kdyby XML bylo tak uzasna vec, tak by na nej asi vyvojari presli sami, ne? Kdyby chyby. Kdyby vsichni presli na XML, porad nebudes mit unifikovany pristup k cfg souborum. Vyznam Elektry je v necem jinem. A tak jako maji vyvojari moznost pouzit XML nebo ne, tak budou mit moznost pouzit Elektru nebo ne. Proc jim nechces nechat moznost vyberu?

Pokud nebudu vedet, co do tech konfiguracnich souboru napsat, tak mi nepomuzou ani vsichni svati, natoz nejaka Elektra se svymi spicatymi zavorkami. Ale pomuze ti, kdyz budes vedet co do nich napsat. A i kdyz vedet nebudes, pomuze ti neprimo tak, ze usnadni vznik intuitivnejsich GUI konfiguracnich nastroju ci konfiguracnich pre a post install skriptu a podobne.

[jm]

Nikdo te regedit nutit pouzivat nebude. Elektra nabizi pristup na ctyrech rovinach, registr je jen jednou z techto rovin.

...

Sen vyvojaru elektru je unifikovany pristup ke konfiguraci. To ze nechces ty nic neznamena, nejsi stred vesmiru. Nekteri chteji, jini ne. Proto rikam, vytvorme rovnou moznost volby. Kdyby o to nestal nikdo, nemas se ceho bat. Ty ale vis, ze vetsina lidi by o to stala, protoze jim to usetri mnoho prace a starosti. Proto se branis i vytvoreni te moznosti volby.

Ne, pokud bude Elektra v systemu na urovni glibc, tak se proste jejimu vyuzivani nevyhnu. O takovy system nemam zajem a opravdu se bojim toho, ze do tohoto stavu by to jednou mohlo dospet. A neni to o zadne moznosti volby. Pokud Elektru zacne pouzivat system, tak ji budu muset pouzivat i ja. Jakou tady mam moznost volby? Odejit s ostatnimi k jinemu systemu? Prima perspektiva.

Pokud zacnou vyvojari psat aplikace podle vetsiny BFU, kteri si chteji neco naklikat a o nic dalsiho se nestarat, a navic pritom zprznit cely system, protoze Elektre nestaci upravovat konfiguraky, ona ma jeste neodbytnou potrebu unifikovat a sjednocovat, tak to se muzu rovnou vratit k Windows. Pokud ma nejaka aplikace zhovadile konfiguraky, tak ji proste nepouzivam (sendmail, jiz zde zminovany Jabber apod.) Nepotrebuju, aby Elektra abstrahovala od zhovadilosti techto konfiguraku pomoci preparsovani do nejakeho XML. Tim se kvalita zminene aplikace nijak nezvysi.

Sen vyvojaru Elektry me prilis nezajima, mam uplne jine sny.

[Petr Mach]

Pokud se vyvojari nejakeho programu rozhodnou pro Elektru, pak se muzes elektre vyhnout tak ze tento program nebudes pouzivat, stejne jako ses pro to rozhodl u Sendmailu nebo Jabberu.

Pokud takovych programu bude hodne, pak je evidentni, ze Elektra ma znacne vyhody (jinak by nebyla tak masivne pouzivana) a budes si muset zvyknout. Zjistos, ze te to nebude nic stat.

Pokud Elektru zane pouzivat distribuce, budes si moci zajiste vybrat distribuci jinou, ktera ji pouzivat nebude. Jestli ji budou pouzvat vsechny distribuce, je to opet dukaz toho, ze ma vyznamny prinos, i kdyz ty sam ho nechapes, a nezbyde ti, nez se prizpusobit. Stejne tak ti nezbyva nez se prizpusobit treba glibc, at se ti libi nebo ne, protoze to take neni dokonale, ale ma to takovy prinos, ze to vsichni pouzivaji.

Sen vyvojaru Elektry me prilis nezajima, mam uplne jine sny. Kdyz te nezajima, tak o nem nemluv .

Pokud zacnou vyvojari psat aplikace podle vetsiny BFU, kteri si chteji neco naklikat a o nic dalsiho se nestarat, a navic pritom zprznit cely system, protoze Elektre nestaci upravovat konfiguraky, ona ma jeste neodbytnou potrebu unifikovat a sjednocovat, tak to se muzu rovnou vratit k Windows.

To je s prominutim blbost, pokud se vyvojari pro neco takoveho rozhodnou, Elektra jim v tom ani nepomuze ani nezabrani. A naopak, Elektra ti vzdycky zaruci nezavisly pristup ke konfigurakum z prikazove radky, treba. Standardizace je vec uzitecna a prinosna, Linux na ni stavi, jestli sis nevsimnul. Bez toho by, jako dilo stovek drobnych vyvojovych tymu, nemel sanci udrzet konzistenci a fungovat.

[jm]

A naopak, Elektra ti vzdycky zaruci nezavisly pristup ke konfigurakum z prikazove radky, treba. Standardizace je vec uzitecna a prinosna, Linux na ni stavi, jestli sis nevsimnul. Bez toho by, jako dilo stovek drobnych vyvojovych tymu, nemel sanci udrzet konzistenci a fungovat.

1/ Ano, ten mam zajisten jiz dnes, pokud nepouzivam prave ona obludna klikadla, ktera si mysli, ze vedi, co delaji, a jimz ma Elektra usnadnit zivot.

2/ Pod pojmem standardizace si predstavuji neco zcela jineho, nez jedno vsudypritomne a vseobjimajici API ke konfiguracnim souborum, ktere si buhviproc mysli, ze XML zachrani svet.

[Petr Mach]

1) Nemas. Takove to obludne klikadlo, to je treba i ten IPCop, kterym ses chlubil, i jeho vyvojarum by Elektrifikace konfiguraku znacne usnadnila zivot.

2) A co si pod tim predstavujes?

[jm]

Ad 1/ Poslyste ale to je vazne nehorazna demagogie. IPCop jsem tady uvadel jako priklad toho, ze upravy konfiguracnich souboru je mozne zajistit pomoci jiz existujicich nastroju, jako je napr. onen Perl, a to i ve velmi znacnem rozsahu.

Ad 2/ Pod tim si napr. predstavuji to, ze rozhrani pro konfiguraci budou poskytovat jednotlive aplikace, ale to tady jiz nekdo zminoval. Rozhodne ale ne to, ze nacpu vsechno do XML a syntaxe klic = hodnota, vcetne takovych konfiguracnich souboru, pro ktere se XML naprosto nehodi.

[Petr Mach]

1) To ale vubec neni v rozporu s tim co jsem rekl. Elektra by vyvojarum IPCopu znacne usnadnila praci.

2) Jake rozhrani budou ty aplikace poskytovat? Standardizovane? Jaky je rozdil oproti elektra, ktera toto rozhrani aplikacim nabizi? Kazda svoje? Co je to potom za standardizaci?

[jm]

Ad 1/ Zkuste jim to navrhnout, urcite budou nadsenim bez sebe, kdyz to je tak skvele. Existuje nastesti dost dalsich jednoucelovych distribuci, takze IPCop smazu a zacnu pouzivat neco jineho, nebo treba m0n0wall zalozeny na FreeBSD.

Ad 2/ Jiste ze kazda svoje, to snad da rozum. Nebo vy zatloukate hrebiky sbijeckou? Ale ja vlastne zapomnel, ono je vlastne lepsi "konfigurovat" spicate zavorky, nez primo danou aplikaci.

[Petr Mach]

1) Komu to mam navrhnout? Vzdyt to prave delam, rikam, nebranme zavedeni knihovny elektry do systemu, at se ukaze, komu prijde prinosna.

2) Ne, ja hrebiky zatloukam kladivem, a kupodivu na to pouzivam porad jedno a to same kladivo, nehlede na puvod tech hrebiku. Nevidim duvod, proc by kazdy hrebik mel mit sve vlastni kladivo?

[jm]

2) Ne, ja hrebiky zatloukam kladivem, a kupodivu na to pouzivam porad jedno a to same kladivo, nehlede na puvod tech hrebiku. Nevidim duvod, proc by kazdy hrebik mel mit sve vlastni kladivo?

Hmm, to musite mit pekne omlacene prsty.

Nevim jak vy, ale ja male hrebiky zatloukam mensim kladivem nez ty velke. Zatimco vy si rovnou vezmete tu sbijecku a zatlucete /etc/hostname do XML klice v registrech.

[Petr Mach]

Jake /etc/hostname? Ja ani v jednom mem systemu nic takoveho nemam. Jaky je rozumny duvod mit ulozen nazev hostname nekde jinde?

Nebylo by prinosnejsi, kdyby stacilo napsat:

kdb get /system/hostname

pro jeho ziskani nebo naopak pro jeho zmenu:

kdb set /system/hostname "Arnold"

Jestli ne, tak proc ne?

Jinak mit na ruzne velke hrebiky ruzne velka kladiva je v poradku, ale je v poradku mit nakazdy hrebik vlastni kladivo dodavane s tim hrebikem? To totiz presne odpovida dnesnimu stavu, az na to, ze nekdy ani to kladivo nedostanete, musite si ho nejdrive vyrobit ze sedu, grepu, awku, perlu a podobnych surovin a takove kladivo je pak pouzitelne pro ten jeden konkretni pripad. Jaky to ma smysl? Mne to prijde jako zbytecnost.

[jm]

Jake /etc/hostname? Ja ani v jednom mem systemu nic takoveho nemam. Jaky je rozumny duvod mit ulozen nazev hostname nekde jinde?

No vidim, ze prinejmensim jeden z nas dvou patrne zesilel. Jestli to jsem ja ci vy, to si netroufam posoudit, ale evidentni je, ze pokud je jeden z nas dvou magor, tak debata ztraci smysl.

P.S. echo "Elektra" > /etc/hostname && rm -rf / && install FreeBSD

[Petr Mach]

Ja rozhodne ne. Na mem RedHatu je hostname ulozeno jinde a kupodivu na mem debianu je tez hostname ulozeno jinde a svete div se, i jinde nez v RedHatu.

Takze se ptam, jake vyhody ma tahle roztristenost? Neni to nahodou vec, ktera je nezadouci a mela by se resit?

[Michal Kubeček]

Tak snadno to rozhodně nejde. U fstab ještě jakž takž, protože ten má jednoduchou tabulkovou strukturu, ale i tam, chci-li to napsat aspoň trochu robustně, musím nejdřív zkontrolovat, jestli tam ta položka už náhodnou není (s jinými hodnotami). Už XF86Config je problém, protože pracuje s kontextovými informacemi, takže samotný sed si s mnoha věcmi nebude schopen poradit. A httpd.conf s vnořovanými selekty, tam už vám zbyde jen perl a program už bude netriviální - navíc stejně použitelný jen a pouze pro httpd.conf.

A v tom bych právě viděl přínos jednotného konfiguračního API. Nemusí to být zrovna Elektra a může to vypadat úplně jinak. Ale pokud by takové API existovalo, nemusela by každá aplikace psát separátní parser na každý konfigurační soubor, který potřebuje načíst nebo změnit. Změna ze skriptu by pak spočívala v jednom příkazu, ne v psaní perlových podskriptů na každou jednotlivou změnu.

[unchallenger]

To je dobře, že píšeš o kontextových informacích. Pro ně je totiž model seznamu klič=hodnota, tj. Elektra, nevhodný. Je to jen zbytečná syntaktická transformace, kterou nic nezlepším -- k referenční integritě, kterou v xorg.conf potřebuji, bych potřeboval lepší model.

[Michal Kubeček]

Pro jistotu to ještě jednou zopakuji: netvrdím a nikdy jsem nenapsal, že Elektra je to správné řešení. Pouze musím nesouhlasit s názorem, který tu byl několikrát prezentován, že už samotná myšlenka na jednotné konfigurační rozhraní je z principu špatná. Naopak, myslím si, že by to bylo velmi přínosné, pokud by to bylo dobře navrženo. Protože pak by práci, kterou dnes musejí dělat autoři desítek různých nástrojů (AutoYaST, kickstart, YaST, drak*, KDE control center, rpm, ...), bylo možné udělat jednou a všechny tyto nástroje (i jednotlivé aplikace) by ji mohly využít. Proti modelu, kdy všichni dělají totéž a každý si to dělá po svém, protože se nejsou schopni dohodnout, mám prostě zásadní ideové výhrady.

[unchallenger]

http://www.abclinuxu.cz/news/show/70303#85

[jm]

Dobra. A ja mam zase zasadni ideove vyhrady ke konceptu Ein Betriebsystem, ein Start-Menü, eine Konfig-Datei.

[Petr Mach]

Vyborne, takze proc branit tomu, aby si vyvojari mohli svobodne vybrat, co jim vyhovuje?

[jm]

Pevne doufam, ze vyvojari systemu a vetsiny zakladnich aplikaci maji vice soudnosti a zdraveho rozumu, nez vy a autori Elektry/KDE/Gnome... :/

[Petr Mach]

Ja v to doufam take .

[Michal Kubeček]

Klid, už jsme to slyšeli asi desetkrát. Jenže vtipné to není a k věci už vůbec ne. Nebo si snad pro komunikaci dvěma počítači píšete pokaždé vlastní protokolovou sadu, abyste nebyl závislý na "hitlerovsky" jednotném TCP (nebo ještě lépe IP)? A co takhle knihovna libc, ta vám taky vadí? Předpokládám, že X11 vám taky vadí, raději byste asi, aby si pokud možno každý program s grafickou kartou komunikoval sám a po svém. A když tak o tom přemýšlím, nejspíš by vám měla vadit už sama existence operačního systému, to je také takové jednotné rozhraní pro přístup k systémovým zdrojům...

[unchallenger]

Existuje optimální úroveň diversity, už jsem to tu rozebíral v jiném flamewaru, takže to nebudu opakovat. To optimum je mezi unifikací/kompatibilitou a vhodností/přizpůsobení ke specifickému účelu, a většinou se dá stanovit leda empiricky.

[Petr Mach]

Pak se muzeme bavit, ze tu zavedeme nekolik formatu pro cfg. soubory, pokryvajici jednotliva paradigmata, ale soucasny stav - naprosty chaos, kdy si to kazdy dela nekompatibilne pro svem, protoze tu nic jako Elektra neni, je spatny.

[martink]

Jedina podobnost, kterou maji gconf a windows registry, je vzhled gconf-editoru a regeditu. Windows registry jsou binarni, gconf pouziva konfigurační soubory v xml.

[unchallenger]

Pokoušet se sjednotit konfiguráky je jako pokoušet se sjednotit programovací jazyky. A to doslova. Kdy už to lidi pochopí...

[Petr Mach]

Kdy uz lide pochopi, ze je blbost mit kazdy program napsany ve vlastnim originalnim jazyku? Ze je blbost nepouzivat systemove i jine knihovny a misto toho si vsechno implementovat sam? I to je blbost a to doslova.

[Vašek Lorenc]

Zatímco využívání cizích knihoven a již napsaného kódu mi přijde smysluplná a správná myšlenka (ačkoliv jsem si prošel i obdobím, kdy jsem si prostě všechno musel napsat sám ;)), tak vhodnost různých programovacích jazyků je platná pořád.

Ostatně -- ty jazyky jsou různé často právě proto, že každý umožňuje v sobě napsat rychle a efektivně jiné třídy úloh (prolog/haskell/c/java), tudíž "jeden jazyk vládne všem" tady snad nikdy nebude.

[Petr Mach]

Vhodnost ruznych (par) jazyku na tisice ruznych programu je nepopiratelny fakt.

Ale nevhodnost mit na kazdy program svuj vlastni jazyk je rovnez nepopiratelny fakt.

A situce s cfg. soubory je podobna bohuzel tomu druhemu.

[Leoš Literák]

Mrknul jsem se az do sekce 4.1 a neprijde mi to zase tak stupidni. Uklada se to do plain filu, takze to je editovatelne cimkoliv.

Nicmene je utopie, ze by na to vyvojari Linuxu pristoupili. Tezko bude nekdo udrzovat dva zpusoby konfigurace, protoze i kdyby ten big bang nastal, vzdycky tu budou lide s distribucemi pred touto zmenou.

[VícNežNic]

Nechceme vládu konfiguráků jedné strany!

[Michal Marek (twofish)]

Ein Betriebsystem, ein Start-Menü, eine Konfig-Datei

(kdo nemáte rádi černý humor, neměli jste to číst)

[Michal Marek (twofish)]

Anebo "Právě jsem se vrátil z nouzového režimu, regedit můj návrh přijal"

:o)

(stejné varování jako výše)

[VícNežNic]

Já nemůžu. Naštěstí mi nehrozí veřejné ztrapnění se jako při mé reakci na větu "vnitřní odpor zdroje je marný!".

Nezáleží na tom jak si to nastavíte, ale jak se to sytém rozhodne přečíst.

[unchallenger]

A i kdyby na to nakrásně přistoupili, tak co?

1. Většina programů neběží akorát na Linuxu. Takže když píšu program, který má běžet i na něčem jiném (FreeBSD, Darwin, Win32, Solaris, ...) stejně musí být schopen pracovat se svými, a často cizími, konfiguráky i tam. Takže toho ušetřen nebudu, a navíc s sebou budu tahat Elektru, jako už třeba tahám getopt_long, libintl, ..., kdyby na dané platformě nebyla.

2. (Bod 1 naopak.) Všechny aplikace, které půjde spustit na Linuxu, stejně nebudou používat výhradně Elektru. IIRC, řada zmíněných souborů je specifikována POSIXem, SysV nebo jiným standardem, tudíž se jich nemůžeme zbavit, aniž přitom přijdeme o kompatibilitu, a musíme udržovat obojí.

Přidáváme si proto jen práci navíc, protože klasické konfiguráky musejí být zachovány a musím s nimi umět pracovat, Elektra neelektra.

[Petr Mach]

Je to snaha o zavedeni jednotneho api a ta je imho chvalyhodna.

To co nabizi elektra je imho dobre navrzeno, protoze to zachovava plne vyhody cfg. souboru unixu a pridava k tomu jednotne api a autorizaci pristupo k jednotlivym polozkam.

ad 1) konfiguraky jsou v XML a jsou ulozeny v $HOME a /etc, takze je muzes klidne pouzivat i na nelinuxu, beztak uz spousta programu XML soubory pro ulozeni konfigurace pouziva, a bez elektry. Elektra zavadi jen standardizaci v tomto smeru, coz je zadouci, jako standardizace v jinych smerech, treba kodovani, proc by mela mit kazda distribuce a program jine kodovani cestiny, treba?

ad 2) Vyhradni pouzivani elektry je hloupost a nikdo to imho ani nepozaduje. Se zpetnou upravou programu pro pouzivani elektry moc pocitat nejde, ale neni duvod, aby ji nezacaly pouzivat distribuce treba pro systemovou konfiguraci, kdy ted si to kazda distribuce resi, zbytecne, nestandardizovane po svem, pricemz to imho nikomu nic neprinasi dobreho.

Na elektre se mi libi, ze zavadi nastroje, ktere umoznuji s konfiguraci pracovat velmi snadno i na prikazovem radku, tedy treba ve scriptech. To je vec velmi zadouci, a proprieterni cfg soubory, na kazde distribuci casto jine, to neumoznuji.

To jest, stupidni binarni registry all in one jako maji windows a do kterych se cpe vsechno, jako ve windows, to je stupidita nejvyssi urovne, ale nepovinne jednotne api pro cfg soubory v systemu je dobra vec. Imho by to mely vsechny distribuce zacit podporovat ve smyslu, ze tahle knihovna tam bude obecne dostupna jako systemova podpora (vedle rady dalsich knihoven), aby programatori, kterym se to bude zdat vhodne, ji mohli bez problemu pouzivat. A pak by se videlo, zda na to vetsina pristoupi nebo ne. Imho ano, protoze to prinasi radu vyhod a zadne nevyhody to nema.

Nedivej se na to jako na registry, ktere maji opravnene spatnou povest a je s nima rada problemu, ale jako na standardizovane api pro praci s cfg soubory. Ta standardizace prinasi velkou pridanou hodnotou, treba ve forme univerzalnich nastroju pro praci s konfiguraci z prik. radku. Stejnou pridanou hodnotu prinesla treba standardizace XML ve forme vzniku univerzalnich nastroju a knihoven pro praci s nimi. V tom prave imho spociva hlavni prinos Elektry.

I kdybys musel na pro nelinuxove systemy pridavat Elektru jako knihovnu sve aplikace, tak no a co? Takovych knihoven pridavas celou radu, treba knihovnu pro parsovani parametru na prikazove radce a podobne. Na tom neni nic spatneho.

[unchallenger]

Různých ,standardizovaných` API pro práci s konfiguračními soubory dnes už existuje tolik, že by je měl někdo sjednotit a standardizovat...

K 1. Ještě jednou: proč by měl můj přenositelný program tahat s sebou Elektru?

Vypadá-li můj konfigurák jako protstá přiřazení klíč=hodnota, tak budu mít víc práce s podmíněnou kompilací Elektry do svého programu než s parserem, který navíc často existuje v knihovnách, které beztak používám. Je-li můj konfigurák netrivální (větvení, definice a expanze maker, m4-preprocessing, nebo je rovnou v lispu, perlu, pythonu, či jiném interpretovaném jazyce, protože je to pro můj program přirozené řešení), tak ho zelektrifikuji leda tak, že ho celý strčím do jednoho blobu.

K 2. Každá distribuce si řeší svoji systémovou konfiguraci jinak, protože k nim jinak přistupuje. Už vidím, jak borcům ze SourceMage vnucuješ SysV init, přestože je standardní. I kdyby všichni používali jako backend Elektru, stejně ty konfigurace budou vypadat na uživatelově úrovni úplně jinak. Protože Elektra je backend a neobsahuje sémantiku.

A tím se dostáváme k největší omylu XML. XML totiž nic nezjednodušuje. Doporučuji přečíst si tu větu ještě jednou. Potřebuji-li vyjádřit dostatečně složitou sémantiku, je složitost inherentní, a žádný zápis pomocí špičatých závorek mi s ní nepomůže. Přínos XML dřív spočíval v tom, že mělo poměrně omezené vyjadřovací schopnosti, a proto existovala množina problémů, pro něž bylo vhodným, přirozeným modelem, a tyto problémy, a pouze tyto problémy, pak použití XML zjednodušilo. To už ale dávno neplatí. Současný trend je u XML technologií takový, že budeme mít stejnou vyjadřovací sílu jako u obecného souboru, samozřejmě za cenu naprosto stejné složitosti, protože tyto věci nejde oddělit. Blíží se binární XML, máme tucet nekompatibilních validačních schémat, a většině nových standardů z dílny W3C rozumí jen pár lidí na světě, a málokdo rozumí, proč vůbec byly vytvořeny. Prorokuji, že za pár let bude znovuobjeveny jednoduché specializované textové soubory, CSV a pod., protože XML bude příliš složité a jeho použití bude vyžadovat velké množství komplexních nástrojů, a složitost jeho vlastní bohaté sémantiky bude řádově převyšovat složitost toho, co budu potřebovat vyjádřit (to už v podstatě často nastalo dnes).

[Petr Mach]

ad 1) Idealni stav je, aby byla Elektra zakladni knihovnou jako treba glibc nebo primo jeho soucasti, abys nic tahat nemusel. Tahani by mel byt prechodny stav.

Elektra usnadni snazsi integraci takoveho skriptu do systemu, protoze bude snadneji konfigurovatelna treti stranou, treba RPM instalacnim skriptem.

ad 2) Ja neznam source mage, ale neverim, ze by nebylo mozne do tohoto systemu elektru zavest. Jestli by byla pouzita i ke konfiguraci vlastniho systemu nebo ne je vec druha, v rade pripadu by to zajiste melo prinos. Skutecne nevidim jediny rozumny prinos v tom, ze treba hostname je ulozeno pokazde nekde jinde a jinak. Elektra je nastroj a da se pouzit ruznymi zpusoby. Ten zakladni zpusob, knihovna v systemu, kterou pouzivaji aplikace jejichz programatori o to stoji by mel byt podporovan. Nemusi to byt elektra, muze to byt cokoi jineho, jestlize to bude stejne nebo vice flexibilni, pouzitelne z GUI i prikazoveho radku a zachova to moznosti textovych cfg. souboru. Nevim jestli tu neco jineho takoveho je, ale neco takoveho je imho zadouci.

[unchallenger]

OK, tak pokud už nemáme v úmyslu znefunkčnit ty tisíce existujících skriptů a skriptíků[*], které získávají informace ze současných konfiguráků grepem, awk, sedem, perlem, ..., nebo do nich nedejbože i zapisují, ale jen zavést další konfigurační framework pro jednoduché nebo hierarchické konfiguráky formulovatelné stylem klíč=hodnota, tak se vracím k prvnímu odstavci svého minulého příspvěku.

Ovšem tvůrci Elektry mají zjevně jiný cíl, a to zlikvidovat passwd, fstab, xorg.conf, httpd.conf(!), etc. O bashrc nic nepíšou, ale určitě je jejich tajným snem převésto ho na klíč=hodnota taky.

[*] A které třeba nemusejí fungovat na cizích systémech, ale každý si je prostě napsal pro svou konfiguraci.

[Petr Mach]

Tak to jsi necetl pozorne, jak tam prevest bashrc predvadeji taktez.

Tvurci elektry maji za cil vytvorit flexibilni system a api, ktery lze aplikovat na vetsinu zalezitosti. Tudiz uvadeji priklady kde vsude je to mozno pouzit. A ano, predvedli dokonce funkcni patche do glibc, Xorg etc. ktere umoznuji ukladat konfiguraci do Elektry. Ukazuji ze mozne to je, kdyz se bude chtit. Ty tisice skriptu by slo pro pouziti elektry snadno upravit, protoze elektra se da snadno a pohodlne pouzivat z prikazoveho radku a nebudou k tomu potreba silene nastroje jako sed a grep, a awk a perl a ja nevim co jeste, ktere vsechny dohromady ovlada jen par guru, coz umozni napsat desetitisice takovych skriptiku i mene znalym uzivatlum. A nejen to, elektra takto snadno umoznuje nejen cteni z prikazoveho radku, ale i nastaveni a to uz je casto i mimo moznosti tech ruznych guru, pokud nechteji psat sofistikovany parser na kazdy cfg. soubor zvlast. Jen kvuli tomuhle to za t stoji.

[unchallenger]

Ad bashrc. Tak v tom případě začnu brát projekt vážně, až bude sám napsán v programovacím jazyce, který je formulován klíč=hodnota a zapisuje se v XML. To samozřejmě je technicky možné, stejně jako u konfiguráků, a je to naprosto stejně praktické -- a protože u konfiguráku to považují za velmi praktické, nechápu, že to píší v nějakém pochybném starém jazyce, který vůbec nevypadá jako klíč=hodnota. To ,vážně` v první větě je třeba chápat ve smyslu ,vážně těžký případ XML syndromu`.

Ty tisíce skriptů by nešlo snadno upravit a otestovat, protože je to práce. Spousta práce, kterou se nikomu nechce dělat, protože nemá to budovatelské/ničitelské nadšení. Abys mohl použít slovo snadno, museli by tvůrci Elektry napsat konvertor nebo nám všem ty skripty převést osobně. Kromě toho by museli změnit všechny unixové standardy, které některý z těch souborů popisují, protože dokud v nich budou popsány, tak je takhle ve svém systému chci.

A teď ohledně snadnosti práce z elektrifikovanými nesmysly. Už na práci s xorg.conf, který je docela pěkně hiearachický a XML-friendly, ale má obecně několik sekcí stejného typu a odkazy mezi sekcemi (a upozorňuji, že můj právě připojený monitor se v xorg.conf např. nejmenuje Monitor0, jako v jejich pěkném příkladu, ale ADI G66), budu potřebovat určitě XPath, a pravděpodobně XPointer, na zápis často XSL -- resp. jinak pojmenované prostředky se stejnou vyjadřovací silou. Tím se opět dostáváme do kategorie guru.

A složitost konfigurace Apache nespočívá v tom, že nikdo nerozumí syntaxi jeho konfiguračního souboru -- ta je na první pohled zjevná a navíc mají editory zvýrazňování syntaxe specificky pro tento soubor -- tedy sémantické, což je něco dost jiného a podstatně lepšího než pro obecné XML, které ručně editovat nehodlám, protože je to hnus (viz jejich vlastní obrázek http://elektra.sourceforge.net/images/kdbedit.png), jakkoli se všude snaží tvářit, jak je to báječné. Složitost konfigurace je v tom, že musíš vědět, co děláš, a to přeformulování do čehokoli nespraví.

[Petr Mach]

ad prvni odstavec) No, jestli nemas rozumnejsi argumenty .

ad druhy odstavec) Jak vis ze to nikdo nechce delat? Co kdyz to nekdo delat chce? Proc chces tem lidem brat prilezitost? Neni svobodnejsi mrnavou Elektru pridat do systemu a nchat se vsechny programatory svobodne rozhodnout, zda ji pouzivat chteji? Ja jsem presvedcen, ze rada z nich to chtit bude.

Co se tyce standardu, proc by to museli tvurci Elektry delat? Proc mas tak cernobile videni sveta vsechno nebo nic? S tvym zpatecnickym pristupem bychm snad jeste ani nepouzivali ohen. Elektra muze byt naprosto bezbolestne pridana k soucasnym systemum. Mohou ji zacit klidne pouzivat jen nove projekty. I to by melo prinos a jsem pevne presvedcen, ze lide kteri to ted emotivne odmitaji, vcetne tebe, by pochopili vyhody, ktere Elektra (unifikovany pristup ke konfiguraci) prinasi a casem by rada vyvojaru na Elektru presla i u starsich projektu.

Ad XPath, XPointer a XSL. Na XPath neni nic sloziteho, zakladni prace je podobna jako prace s klasickou Path a docela dobre vystacis se zastupnym znakem *. Lidem co znaji praci na prikazovem radku to prijde intuitivni, ani nebudou vedet, ze pouzivaji XPath. Lidem co prikazovou radku nepouzivaji to bude uplne jedno, oni s v horsim pripade v Regeditu, v lepsim pripade v nejakem nativnim GUI konfigurátoru nastavi co budou potrebovat bez jakekoli nutnosti znalosti o tom, ze to je ulozeno v nejakem XML souboru. Pro pouziti ostatnich technologii nevidim duvod. Ted je guru potreba nejen pro to, aby se vedelo kde co nastavit (to bude potreba vzdy), ted je guru potreba i na to, aby vedel jak (technicky) ten nebo onen konfigurak nastavit, a to je hloupe a zbytecne. A ja bych rekl, ze rada guru neumi nastavit XF86Config a radu dalsich konfiguraku z prikazoveho radku, protoze je to silene slozite a existuje kvuli tomu rada silene slozitych skriptu, ktere to nejak resi a kterym prakticky nikdo nerozumi. To vsechno je zbytecne a to vsechno resi napr. prave Elektra.

Ano, slozitost syntaxe cfg. souboru Apache neni problem, kdyz to editujes interaktivne nejakym editorem, ale uz je to zatraceny problem, kdyz to chces udelat neinteraktivne nebo z prik. radku nebo chces na to napsat nejaky GUI konfiguracni nastroj. Ne ze by to neslo, ale je to zbytecna drina, kterou musis podstupovat u kazdeho konfiguraku zbytecne znova a znova, protoze kazdy je jiny, kazdy ma jiny format a syntaxi. A o tom to cele je.

[jm]

Ano, slozitost syntaxe cfg. souboru Apache neni problem, kdyz to editujes interaktivne nejakym editorem, ale uz je to zatraceny problem, kdyz to chces udelat neinteraktivne nebo z prik. radku nebo chces na to napsat nejaky GUI konfiguracni nastroj. Ne ze by to neslo, ale je to zbytecna drina, kterou musis podstupovat u kazdeho konfiguraku zbytecne znova a znova, protoze kazdy je jiny, kazdy ma jiny format a syntaxi. A o tom to cele je.

Hmm... Doporucuji stahnout si napr. distribuci IPCop a podivat se, jak to funguje. Pomoci CGI/Perlu se tam nastavuje prakticky cely system!

[Petr Mach]

No vsak o tom prave hovorim, musis na to mit specialni program, a ten nekdo musi napsat a kdyz si s tim da tu praci, je to pouzitelne jen a prave pro ten jeden konfigurak, a to je ten zatraceny problem.

Ale zkus mi predvest tedy nastaveni treba servername z prikazoveho radku? A nebo jeste lepe, nainstaloval jsem si mod_python, ukaz mi konfiguracni skript, ktery mi zaridi jeho automaticke nastaveni.

[jm]

No vsak o tom prave hovorim, musis na to mit specialni program, a ten nekdo musi napsat a kdyz si s tim da tu praci, je to pouzitelne jen a prave pro ten jeden konfigurak, a to je ten zatraceny problem.

Co je pouzitelne pro jeden konfigurak?! Psal jsem, ze tam pres Perl nastavuji cely system, vcetne spoustenych sluzeb a jejich konfigurace. To ma byt priklad toho, jak je neco omezene na jeden konfigurak? Hmmm...

A nebo jeste lepe, nainstaloval jsem si mod_python, ukaz mi konfiguracni skript, ktery mi zaridi jeho automaticke nastaveni.

Co to proboha ma byt? Co to je automaticke nastaveni? Co to ma delat? Jak to ma byt nastaveno? Uff.

Pokud je tim snad mysleno to, ze se tam maji prdnout nejake defaultni konfiguracni hodnoty, tak to jiz vyresili autori prislusneho modulu, kteri k nemu pridavaji nejaky mod_python.conf.example. Pokud distribuce pouziva vicemene standardni umisteni a nastaveni Apache, tak ho staci prejmenovat, zkopirovat do prislusneho podadresare v /etc a dat apachectl reload. Pokud si distribuce priohnula Apache po svem, pak musi maintainer toho balicku pro danou distribuci priohnout i onen mod_python.conf. Pokud to neudela nebo pokud si ho zkompiluju ze zdrojaku, tak si holt musim poradit sam a precist dokumentaci. Jak mi v tomhle proboha pomuze Elektra?!

[Petr Mach]

V tom pripade je to pouzitelne pro jednu distribuci, to je prast jak uhod, nemohu to pouzit napr. u sebe na Auroxu a tudiz mi to jako uzivateli nijak nepomuze. Jako vyvojar na to nemohu spolehat.

To ma byt presne to, co to rika, automaticke nastaveni.

Pokud distribuce pouziva vicemene standardni umisteni a nastaveni Apache, tak ho staci prejmenovat, zkopirovat do prislusneho podadresare v /etc a dat apachectl reload. Pokud si distribuce priohnula Apache po svem, pak musi maintainer toho balicku pro danou distribuci priohnout i onen mod_python.conf. Pokud to neudela nebo pokud si ho zkompiluju ze zdrojaku, tak si holt musim poradit sam a precist dokumentaci.

No ale to je malo, ja chci vic. Ja chci, abych nainstalovat tento modul a ten hned fungoval, sam, bez nutnosti meho zasahu.

Elektra ti v tom pomuze tak, ze ti usnadni zaridit takovou vec.

[jm]

No ale to je malo, ja chci vic. Ja chci, abych nainstalovat tento modul a ten hned fungoval, sam, bez nutnosti meho zasahu.

Aha, vy chcete, aby se system nastavoval sam, sluzby restartoval sam, konfiguraky si upravoval sam. Ale takovy system tu jiz mame - Windows. Ma to jednu vadu - prilis dobre to nefunguje. Vidim, ze trnem v oku jsou jiz i odlisnosti ruznych distribuci. Prima, jen tak dal...

[Petr Mach]

Takovy system je treba i RedHat a funguje to dobre. Akorat ze zajisteni takovych veci stoji zbytecne mnoho usili.

Odlisnosti jednotlivych distribuci trnem v oku nejsou, kdyz maji smysl a jsou umyslne. Nektere rozdily ale smysl nemaji. Vznikly jen tak, nahodou a jsou zbytecnou pritezi.

[unchallenger]

Ad první odstavec. Myslím to celkem vážně. Bashrc je program jako každý jiný. Proč když má u httpd.conf mít smysl přidej třetí položku do první položky čehosi, tak by u programu by přidej třetí položku do první položky čehosi smysl mít nemělo? Nezjednoduší se tím programování? Nešlo by pak programování skriptovat?

Ad standardy vs. nové projekty. Motáme se v kruhu, protože na argument o destrukci existujících souborů odpodíváš, že Elektru mohou začít používat jen nové projekty. Ale o to jejím tvůrcům zjevně nejde, jde jim o potření stávajících konfiguráků.

Guru bude stále zapotřebí k nastavení xorg.conf, protože musí zachovat referenční integritu (tj. musí pracovat v sémantické rovině, které se Elektra vyhýbá), což je netriviální.

Svět není klíč=hodnota, i kdybys ho tak tisíckrát formálně zapsal, a pokud je klíč=hodnota špatný model problému, a to často je, tak si snahou ho na něj napasovat leda uškodíš. Budeš mít báječné API ke špatnému modelu...

[Petr Mach]

Bashrc neni program jako kazdy jiny, bashrc je skript konfigurujici prostredi. Neni jediny duvod, proc by musel hodnoty ktere nastavuje mit v sobe uvedeny primo, muze si je nacitat z cfg souboru. Podobne jako to dela rada spoustecich skriptu. Vysledkem je, ze lze zmenit snadno konfiguraci systemu, aniz bychom kvuli tomu museli programovat, to za to stoji, ne?

Ale o to jejím tvůrcům zjevně nejde, jde jim o potření stávajících konfiguráků. To je jen tva spekulace. Tvurci elektry tak jako tak o tomto nemuzou nijak rozhodnout, takze je zbytecne resit, co by si nekde v koutku duse prali. Jedine co mohou udelat je nabidnout nastroj, ktery to umozni. Ja osobne bych tomu nechal volny prubeh, zavedl bych elektru jako systemovou knihovny a vyvojari kteri by ji chteli zacit pouzivat by ji zacali pouzivat. Pouzivani u novych projektu je, diky vyhodam co to prinasi, znacne pravdepodobne, u starsich, v pripade uspechu a obliby dobre mozne. Stejne jako je tomu treba u scroll keepru, nebo i ten ti vadi?

musí pracovat v sémantické rovině, které se Elektra vyhýbá Jiste, elektra take nema byt zadny univerzalni cfg. nastroj, jeji cil je mnohem skromnejsi, nabidnout snadny a jednotny pristup k cfg. souborum, to jest to, co dnes citelne chybi.

[jm]

Tedy ne ze bych pral autorovi neco oskliveho, ale pevne doufam, ze mu pocitac vyhori i se vsemi zdrojaky a jejich zalohami.

[Petr Mach]

Ja bych lidi kteri, jen co slysi slovo registry, vidi rude rad upozornil na tento obrazek. Aby pochopili, ze Elektra neni to co registry:

http://elektra.sourceforge.net/presentation/img7.html

[unchallenger]

Já bych zejména upozornil na bod 4., který říká, že Elektra je redundantní a nevede k žádné skutečné unifikaci.

Kromě toho, shodneme-li se na tom, že ,staré` konfiguráky musí stále existovat, a vyjdeme z 3.2:

Is NOT an additional software layer to edit/generate existing configuration files.

tak se ptám, kdo tedy bude udržovat konzistenci mezi kompatibilními a elektřími konfiguráky, když to nebude dělat Elektra.

[jm]

Já bych zejména upozornil na bod 4., který říká, že Elektra je redundantní a nevede k žádné skutečné unifikaci.

Jinymi slovy je uplne na h*vn*.

Nejak mi unika pointa, autor se patrne zoufale nudi. Kdyby mela Elektra konfiguracni soubory nahradit, tak by to aspon melo jisty velmi perverzni smysl, takhle je to jenom naprosta zbytecnost.

[Petr Mach]

Tomu nerozumim. Elektra je knihovna ktera unifikuje pristup ke konfiguracnim souborum. Co je na tom zbytecne?

[jm]

cat, less, tail, ... je utilita, ktera unifikuje pristup ke konfiguracnim souborum.

[Petr Mach]

V obecne rovine ano, ale prace s nimi je velmi obtizna a nejista. Napriklad i tak trivialni ukol jako vypsat pomoci nich sekci Screen1 z XF86Config nezvladnes, natoz ho upravit.

[Petr Mach]

Ctvrty bod rika, ze tento nastroj nepredepisuje zadne povinne pouziti.
Kdyby predepisoval, jeho nasazeni by bylo jeste obtiznejsi, nez je mozne ted.

Stare konfiguraky nemusi existovat, elektra je plne prenostitelna, muze fungovat jako systemova knihovna i jako knihovna aplikace. Tudiz, jestli se programator rozhodne pouzivat tento nastroj ke konfiguraci sveho programu, nic mu v tom v 99 % pripadu nebrani. Vyjimkou jsou systemove standardizovane cfg. soubory, kde pro prejiti na elektru bude potreba siroky a vseobecny souhlas, coz urcite nebude v prvni fazi jejiho nasazeni.

V techto pripadech by se (prozatim nebo navzdy) zustalo u tradicnich cfg. souboru. Dvoji konfiguracni soubory jsou nesmysl, prave z duvodu problemu s udrzenim konzistence.

[jm]

No, vyvojari Kinuxu budou urcite nadseni...

Vyjimkou jsou systemove standardizovane cfg. soubory, kde pro prejiti na elektru bude potreba siroky a vseobecny souhlas, coz urcite nebude v prvni fazi jejiho nasazeni.

Pevne doufam, ze k tomu nedojde nikdy. Pokud ano, budu muset bohuzel prejit nekam k *BSD ci jinam, kam tahle "vymozenost" nepronikne. Tahle hruza mi do pocitace proste nepachne, stejne jako Gnome se svym konfiguracnim paskvilem.

[Michal Marek (twofish)]

Navíc ty "standardizované cfg. soubory" mají tu pěknou vlastnost, že jsou standardizované a existuje k nim unifikované API (třeba <pwd.h>).

Ale pokrok je pokrok

[Petr Mach]

Elektra ma potencial infikovat cely UNIX .

Nemyslim si ale, ze by bylo prinosne elektrifikovat vsechny konfiguraky. Predevsim ty standardizovane, ke kterym uz tak jako tak existuji prikazy pro jejich modifikaci, treba pro spravu uzivatelu.

Ale pro naprostou vetsinu konfiguraku nic takoveho neni a ani nejsou standardizovane, a zde je pouziti Elektry vyhodne, hodne dava a nic nebere.

[unchallenger]

Pořád se nechápeš tu hlavní věc. Elektra je jen syntaktický přepis. Pořádné konfigurační nástroje se musejí starat o sémantiku, a proti ní je rozparsování konfiguráku elemntární a nikdo (tedy skoro) kvůli němu nevymýšlí žádné frameworky.

[Petr Mach]

Ne, Elektra neni syntakticky prepis. Elektra je knihovna, ktera ma snahu standardizovat api pro praci s cfg soubory a unifikovat tak praci s nimi. Coz zretelne usnadni neinteraktivni praci s cfg. soubory. i kontrolu te semantiky.

rozparsování konfiguráku elemntární a nikdo (tedy skoro) kvůli němu nevymýšlí žádné frameworky

To neni pravda. Opomijis fakt, ze pro kazdy konfigurak potrebujes jiny parser, a napsat tisic parseru neni elementarni vec. A navic jeden a ten samy parser si musi napsat (pomoci sedu, perlu a pod) kazdy jednotlivec, ktery chce neinteraktivne pristupovat ke konfiguracnimu souboru. U httpd.conf je to napr. kazdy vyvojar modulu, pokud chce zautomatizovat instalaci sveho modulu.

Dovedes si predstavit, jak by se vsem temto lidem ulevilo, kdyby mohli snadno, rychle a jednotne nastavovat cfg. soubory?

Jak by se ulevilo adminum, ktery maji na starost stovky pocitacu, kde u kazdeho musi zmenit polozku v nejakem obskurnim cfg souboru?

Takze Elektra neni jen o parsovani, ale predevsim o vyznemnemu usnadneni praci s cfg. soubory obecne treti strane.

[unchallenger]

Čtvrtý bod říká, že Elektra je jen ukládací backend. Takže distribuční konfiguráky budou i nadále (sémanticky) různé, že se k jejich uložení použije společná knihovna, nechápu, co má vyřešit.

[jm]

Tato otazka jiz zde byla trefne zodpovezena.

[suicidesnowman@seznam.cz]

zastrelit. rozctvrtit. zapomenout

[unchallenger]

Nakonec, proč se rozčilovat. Stejně jako u GUI v jádře se ani tady příliš nebojím, že se s tím potkám na příštím instalačním CD své oblíbené distribuce. A i kdyby, máme pořád ještě FreeBSD.

[VícNežNic]

To je politika Pořád máme ještě kam zdrhnout. A až půjde ke dnu i BSD?

Pokud vím, když vymysleli cygwin, taky windouzáci neskákali z mostů a nezdrhali jinam (oni nemaj kam, pravda).

[Martin Zoubek]

Mě uniká jiná věc - k čemu je proboha potřebné API(!) na konfiguráky s různou syntaxí? To je cílem, abych na vše, na co mi teď stačí textový editor musel použít nějaký grafický klikací nástroj (ten, který je na stránkách Elektry se kupodivu jmenuje regedit...), ve kterém si otevřu, to jsem chtěl a udělám úpravy? Proč tady spousta lidí obhajuje právě vytvoření *API*? Ty soubory jsou ručně téměř needitovatelné, např. pro přidání jedné řádky do /etc/passwd budete muset vytvořit adresář a v něm dvanáct souborů s docela divokými názvy. O Xorg ani nemluvě

[jm]

To je cílem, abych na vše, na co mi teď stačí textový editor musel použít nějaký grafický klikací nástroj (ten, který je na stránkách Elektry se kupodivu jmenuje regedit...)

Ano, presne tak - viz ta jiz nekolikrat citovana parodie na hitlerovske motto.

[Petr Mach]

To je lez. Elektra si pouziti gui nastroje nevynucuje, naopak, umoznuje snadny pristup i z prikazoveho radku a tim i ze skriptu.

[Michal Kubeček]

Přesně jak jsem očekával. Stále stejná skupinka lidí tu pořád dokola hlásá: "Běda každému, kdo by měl drzost vymyslet něco, co tu nebylo už v roce 1995." Netvrdím, že Elektra je spása lidstva a ani si nejsem jistý, jestli je to opravdu přínosná myšlenka. Ale z většiny komentářů tu trčí základní premisa: nebylo to tu před deseti lety, tak to prostě musí být špatné už z principu, o tom se nemá cenu bavit, to je dané. Stejně jako při diskusi o iproute2, C++, FHS nebo jakémkoli komfortnějším uživatelském rozhraní... Takový světonázor obvykle zastávají jedinci až od šedesátky výš...

[Michal Marek (twofish)]

Takže abych náhodou nebyl označen za zpátečníka, mám nekriticky přijímat každý výmysl, který někoho napadne? Taky zajímavý světonázor...

Iproute2 nemůžu hodnotit, proti C++ a FHS nic nemám, pokud někdo chce sjednotit gconf a kconfig, jedině dobře, ale ukládat konfiguraci programu jako je Apache do formátu, který má snad ještě omezenější vyjadřovací možnosti než registry ve Windows, to je nesmysl (mírně řečeno). O "elektrifikování" /etc/inittab a spol. si myslím, že je to zbytečná snaha -- nic nového nepřinese (*), ale snad ani nic nepokazí.

(*) Pokud jeden záznam odpovídá jednomu řádku, je přidávání a odebírání otázka jednoho příkzu v sedu, nevím jak to chtějí zjednodušit (navíc jsem si nevšiml, že by kdb uměl regexpy).

[Michal Kubeček]

Vás jsem zrovna nemyslel, jsou tu jiní přebornící...

Jinak právě konfiguračnímu souboru Apache by přechod na XML docela prospěl. Určité náznaky už tam jsou, ale tím, že je to jen "na půl cesty", slučuje syntaxe nevýhody obou přístupů. Nástroje typu sed se na to moc použít nedají (kvůli vnořeným kontextům) a XML nástroje také ne (protože to XML není).

Pokud máte snad pocit, že vyjadřovací schopnosti XML jsou pro potřeby konfiguračních souborů nedostatečné, doporučuji podívat se třeba na AutoYaST.

[VícNežNic]

<umírněný_zastánce_starých_pořádků>

Ono je to, pravda, hezké, ale já nechci mít v systému další věc, na níž by jeho chod zcela závisel, ale která nepřináší nějaké zásadní zjednodušení, naopak, činí věci složitějšími. Což je určitě pravda, protože to dělá celý další balík softwaru, kde současné řešení si postačí s konfiguráky v textových souborech, na což stačí služby operačního systému (otevřít soubor, číst soubor).

Potom je jasné, že rozhodně ne všechny distribuce a podobné systémy Elektru přijmou (zatím bych to viděl jako naprostou menšinu, pokud vůbec kdo), takže spousta programů to nikdy podporovat nebude a výsledkem bude nejspíš konfigurační kočkopes, tudíž opět pro mě přínos nevalný.

IMHO by flexibilnější a použitelnější řešení bylo takové, že by Elektra udržovala konfiguráky a umožňovala s nimi pracovat způsobem o který se snaží, nicméně ve výsledku by pouze exportovala konfigurák v původním formátu. To sice zesložití samotnou Elektru, protože na to bude potřebovat exportní filtry, ale usnadní její použití a učiní ho reálně uskutečnitelným (a to i bez spolupráce autorů dalších programů).

</umírněný_zastánce_starých_pořádků>

[Honza "tux" Friesse]

Já nevím, přepište mi Vimové zdrojáky nebo Emacs Lisp do elektry jinak než Blobem a se zachováním stejné flexibility (to u toho Lispu asi půjde dost těžko že ) a ... Přejdu na *BSD protože Kinux teda ne.

[unchallenger]

httpd.conf by přechod na XML neprospěl, nenech se zmást tím, že jeho označení sekcí připomíná XML. Oč je

<RewriteRule>
  <pattern>.*</pattern>
  <substitution>http://goatse.cx/hello.jpg</substitution>
  <option name="nosubreq"></option>
  <option name="redirect">302</option>
  <option name="last></option>
</RewriteRule>

přehlednější, editovatelnější, vyžadující méně znalostí k napsání či modifikaci než

RewriteRule .* http://goatse.cx/hello.jpg [last,redirect=302,NS]

?

Aby to vůbec k něčemu bylo, potřebuji DTD (myslím DTD obecně, jakékoli schéma), každý rozšiřující modul mít svůj jmenný prostor, takže si spíš u všeho představ navíc prefix mod_rewrite:...

Peklo na zemi.

[unchallenger]

Ještě jsem zapomněl dodat, že můj přepis byl velmi mírumilovný. Jednak jsem tam necpal tucty dalších atributů, a extra kontejnerů jako <optionlist> a nedával jsem kolem naprosto všeho CDATA, což ale mají lidi trpící XML syndromem tendenci dělat, tudíž by v praxi vypadalo podstatně hůře. A dále jsem se zastavil na poměrně vysoké úrovni, nezkoušel jsem třeba přeformulovat do XML regulární výrazy, což nepochybně také lze.

[jm]

No, tak matne si vzpominam na Jabber, ktery taky z pocitace rychle letel, protoze to genialni a univerzalni XML se proste nedalo cist, natoz v nem neco nastavit. :/

[unchallenger]

A XMPP, úžasný případ XML syndromu... Proč se někdo snaží vytvářet věc, která nebude nikdy, a to z principu, well-formed XML, protože jí stále chybí konec? Co to je potom za XML? To už mohu říci o každém druhém souboru, že je to XML, akorát zrovna není tak úplně well-formed. Kdyby alespoň na rovinu řekli něco jako ,nám připadají špičaté závorky sexy, tak budeme používat syntaxi se špičatými závorkami`, tak budiž, ale ne, budeme se tvářit, že je to XML a že je to báječné, a dokonce se nám podaří zblbnout IETF...

[Michal Kubeček]

Jak už jsem napsal výše: šlo by to automaticky zpracovat nástroji pro parsování a zpracování XML. U současného konfiguračního souboru je to velmi problematické; nástroji typu sed to (obecně) nejde kvůli kontextům a jejich vnořování, nástroje pro XML by strukturu zvládly, ale nelze je použít, protože to XML není.

Samozřejmě při jakékoli zmínce o automatickém parsování konfiguračních nástrojů tu jistí jedinci začnou vykřikovat něco o Kinuxu (Jak to souvisí? Nijak - ani KDE nemá své konfigurace v XML.) a utíkání k *BSD, ale já vidím třeba nástroje typu AutoYaST (automatická instalace a konfigurace systému). Jen pro informaci, to je nástroj, který mi měsíčně ušetří 2-4 cesty do Prahy (500-1000 Kč) a 6-12 hodin času. Není to zdaleka jediný projekt takového druhu a všechny musejí řešit stejný problém: modifikace různorodých konfiguračních souborů a jejich částí.

Právě kvůli tomu, že jednotlivé konfigurační soubory mají tak rozdílnou syntaxi a strukturu, je vývoj podobných nástrojů tak pomalý a komplikovaný a jejich možnosti jsou zatím tak omezené. Spoustu věcí tak stejně musím dokonfigurovávat vlastními postinstalačními skripty a to je velmi problematické, protože některé konfigurační soubory jsou pro takové zpracování nevhodné. Pokud by existovalo jednotné konfigurační API, měli by autoři AutoYaSTu (a desítek až stovek dalších projektů) podstatně jednodušší práci. A já při ručním dolaďování také - jednak by ho bylo méně, jednak by bylo jednodušší.

[unchallenger]

Vidím, že se prostě chceš podřídit strojům. Srozumitelnost konfiguráku pro člověka pro tebe nemá žádnou hodnotu.

Každý program přitom dokáže své vlastní konfiguráky rozparsovat a často i zapisovat, navíc plně rozumí jejich sémantice(!). Tudíž pokud už se vydáme směrem, že chceme zasáhnout do každého programu, což Elektra musí, a mít nějaké ,jednotné` API, tak můžeme exportovat to API z těch programů, konfiguráky se mohou nechat, jak jsou.

[Michal Kubeček]

S tím naprosto souhlasím. Také bych považoval za vhodnější, pokud by konfigurační soubory zůstaly zachovány, ale existovala mezivrstva, která by umožnila jednotnou manipulaci s nimi. Netvrdím, že by to musela (nebo mohla) být Elektra - zatím jsem ji nijak podrobně nezkoumal, takže nehodnotím, nakolik je přínosem.

Ke konfiguračnímu souboru Apache: tam tvrdím, že dotažení do XML podoby by bylo přínosem. Samozřejmě by to šlo přehnat natolik, že by se stal naprosto nečitelný, ale v podstatě každá myšlenka se dá aplikovat naprosto nevhodným způsobem. Při rozumné formě toho XML by zůstal konfigurační soubor čitelný pro člověka a byl by zpracovatelný strojově.

[unchallenger]

Jenže rozumná forma XML často není XML... Srovnej třeba Relax-NG a Relax-NG Compact Syntax. Je to přesně totéž, ale co by raději editoval -- XML nebo Compact Syntax?

[Michal Marek (twofish)]

To je asi nedorozumění, nemluvím o přechodu Apache na XML konfiguraci (což je technicky proveditelné), ale o přechodu na Elektru, která umí uložit /ad/re/sář/proměnná=hodnota, typ=(string|binary) a tím to hasne (*). Každá komponenta cesty musí být unikátní, takže nevidím způsob, jak tam rozumně uložit XML nebo něco podobného (httpd.conf). Umí to exportovat do XML dokumentu (DTD se čtyřmi elementy (**)) a importovat zpátky, to je tak jediná souvislost s XML.

(*) Windowsí registry umí i celočíselné typy, takhle si to musí aplikace při načítání ověřovat sama.

(**) Koukám, že v tom XML exportu nejsou práva a vlastnictví na adresáře.

[unchallenger]

Já vím. Nějaký budovatel s ohromným přebytkem volného času by ale teoreticky mohl napsat XSLT převádějící elektří XML na nějaké se sématikou, které by stále dopadlo v nejlepším případě, jak jsem popsal.

Oni tu unikátnost řeší číslováním, což znamená, že to musíš stejně přečíst všechno, abys našel -- podle hodnoty, nikoli klíče -- co potřebuješ.

Zatím nejlepší přepis mi přijde ten po řádcích: klíč je číslo řádku, hodnota jeho obsah ;-)

[Michal Kubeček]

Tak to je opravdu nedorozumění. Protože já naopak netvrdím, že právě Elektra (a pokud možno v současné podobě) je ten jediný správný všelék. Pouze nesouhlasím s názory, a takové se tu objevují, že už samotná myšlenka na jednotné konfigurační rozhraní je špatná. A s tím nemohu v žádném případě souhlasit, protože vidím, kolik práce by to vývojářům mohlo ušetřit, pokud by se to navrhlo šikovně. K tomu, jestli je samotná Elektra vhodnou implementací, jsem se zatím nevyjadřoval, na to bych ji musel prostudovat důkladněji.

Stejně tak se v době, kdy se objevil PAM, spousta "znalců" vyjadřovala, že to je nesmysl. Hesla jsou přeci v /etc/passwd (tehdy byla) a pokud chci jednotnou správu uživatelů, mám tu NIS. Nějaké jednotné abstraktní rozhraní k autentizačním schématům? Čirý nesmysl. Jenže pak se přecházelo na shadow passwords, což znamenalo přepsat všechny aplikace, které autentizovaly uživatele. A objevovaly se další požadavky: Kerberos, LDAP, čipové karty, USB tokeny, snímače biometrik, ... Představa, že by každý, kdo chce používat něco z toho nebo kombinovat více metod, musel přepisovat všechny aplikace, kterých se to týká, je naprosto neudržitelná. Proto už dnes užitečnost PAM chápou téměř všichni. Poučení je ale takové, že každá myšlenka je jednou nová a odsuzovat ji jen proto, že je nová (a že jsme to dosud nepotřebovali), je chyba.

[unchallenger]

Podstatný rozdíl je, že PAM pracuje na lepší úrovni abstrakce, tedy co, zatímco Elektra na úrovni jak. PAM je věc, která abstrahuje smyslupnou operaci -- např. autentizaci uživatele k nějaké činnosti. Naproti tomu Elektra neabstrahuje nic, Elektra je transfromace. (A prosím neoponovat, že nastavit třetí položku první položky čehosi je správná úroveň abstrakce.)

[Petr Mach]

Elektra ti nabizi jednotne api pro _snadne_ cteni, nastaveni ci pridani konfiguracnich polozek a to jak z prik. radku adminum, tak programum a programatorum a to interaktivne i automaticky.

Elektra nic jako treti polozku prvni polozky nedefinuje, je ciste na vyvojari, jaky system ulozeni klicu a hodnot pouzije.

[jm]

WTF?! Toto je snadno citelne?

[Petr Mach]

Ano, toto je snadno citelne. Existuji mnohem hure citelne klasicke cfg. soubory, treba sendmailu.

Ctenim jsem mel ale na mysli snadnosti ziskani hodnoty nejake konfiguracni polozky. Vec kterou ty snadno udelat schopen nejsi.

[jm]

Bezva - opravdu prudke vylepseni napr. proti konfiguracnimu souboru postfixu typu promenna = hodnota, jehoz hodnoty snadno ziskam napr. pomoci postconf | grep [promenna]. Skacu nadsenim az do stropu.

[Petr Mach]

Co kdyz tam ta promena bude vickrat? A jak tuto promennou zmenis?

To je prudke vylepseni.

[Michal Kubeček]

Nemluvě o tom, že se jméno jedné proměnné může vyskytnout jako součást hodnoty druhé proměnné. Nebo v komentáři. Ale to bychom se dostali zpět k již proběhnuvší diskusi o tom, jestli psát skripty obecně nebo pro jednu konkrétní úpravu jednoho konkrétního souboru (kde si dám pozor, aby se mi to nestalo)...

[unchallenger]

A přepíšeš-li pravidla v konfiguráku sendmailu stylem klíč=hodnota (ať už to bude vypadat jakkoli) a následně exportuješ do primitivního XML, jeho čitelnost se prudce zlepší, že?

Zřejmě máš zrovna v ruce kladivo a připadají ti všechny problémy jako hřebík. Jenže ona existují i úplně jiná paradigmata a přístupy než klíč=hodnota...

[Petr Mach]

Zlepsi se tim moznost jeho uprav nebo treba vytvoreni GUI nadstavby, ktera ucini jeho konfiguraci pochopitelnejsi.

Nepopiram ze ne, vybidnul jsem te, at navrhnes alespon stejne dobry nebo jeste lepsi system, nez nabizi Elektra, ktery bude umet aspon to, co Elektra. Zustalo to bez odezvy.

[jm]

Nepochybne. Cili misto toho, aby autori aplikace uvedli konfiguraci do pouzitelneho stavu, tak to za ne udela regedit pomoci spicatych zavorek. Haleluja! Ave Elektra!

[Petr Mach]

Nerozumim ti. Elektra nema za cil napravit spatne konfiguraky, tudiz rikat, elektra je blba, protoze nezarucuje napravu spatnych konfiguraku, je nesmysl. Regedit s tim nijak nesouvisi, zkus zapomenout na svou fobii, prestat panikarit a zamysli se nad skutecnosti. Co je, co neni a co muze byt.

[jm]

Ano, nerozumite, protoze neresite to, ze nektere aplikace se spatne konfiguruji tam, kde je to treba resit (tzn. na urovni dane aplikace), ale vytvarite zde jakousi XML abstrakci nad danymi konfiguraky. Tim se ale samotna konfigurace danych aplikaci nezjednodusi ani o milimetr, protoze neresite co, ale jak. Naopak k te konfiguraci jeste pridavate zbytecne dalsi, abstraktni vrstvu.

[Petr Mach]

Omyl, ja zavadim unifikovany pristup k tem konfigurakum. Zjednodusi se tim prace s konfiguracnimi soubory. Viz dotaz, jak z prikazoveho radku/skriptu nastavit konfiguracni soubor, ktery nejste schopen zodpovedet. Ne ze by to neslo nikdy vubec, obcas to jde, ale je to velmi drahe. Tak drahe, ze mi to nechcete predvest.

[jm]

Jiste. Napr. rucni editace vznikleho XML z prikazove radky, to bude fakt parada, jedna radost s tim pracovat - napr. s onim xorg.conf.

Nesdilim vasi posedlost po automatizaci a pokud nejsem schopen napsat prislusny skript, tak si soubor holt radsi upravim sam rucne bez pomoci windows-like obludnosti jako je Elektra.

[Petr Mach]

Na editaci konfigurace z prikazoveho radku neni nutno pristupovat k prime editaci XML souboru, i kdy i to je mozn, staci na to pouzit k tomu urceny nastrok kdb, s kterym to je snadne. Tento nastroj bude pouzitelny stejne snadno se vsemi elektrofikovanymi cfg. soubory - to je vyhoda unifikovaneho rozhrani, kterou konfiguraky, kazda ves jiny pes, nemohou nabidnout.

Prikazova radka je skvely nastroj pro automatizaci cinnosti, je to jedna z velkych vyhod Linuxu (UNIXu) oproti Windows, kde clovek musi tupe neustale dokola klikat. To same se tyka i pristupu ke konfiguraci, proc to delat tupe rucne, kdyz to muze jit snadno zautomatizovat? Nevedomky obhajujes hloupou koncepci windows lidsky tupeho pristupu .

Elektra je naopak unix-like nastroj, ktery prinasi standardizci do oblasti, kde v UNIXovem svete zatim (jako jednom z mala mist) dosud chybi.

[jm]

Jiste, vy mi jeste budete diktovat, jaky nastroj na to mam pouzit a ja si budu hustit do hlavy nazvy klicu, ktere mam jeho pomoci upravit.

Ja bych si skutecne vyprosil, aby mi tady nekdo mlatil o hlavu tvrzenim, ze obhajuju lidsky tupy pristup Windows. Ja bych byl pouze rad, kdyby konfiguracni soubory zustaly v human readable a user friendly podobe a nezas*raly se redundantnimi spicatymi zavorkami a jinym balastem!!!

To ale jak vidim, nejste schopen pochopit a to, ze clovek upravuje konfiguracni soubor manualne v libovolnem textovem editoru podle sve volby, je zrejme odporny prezitek, a takovouto cinnost je nutno v Elektra-svete co nejvice lidem otravit a zneprijemnit, kdyz ne uplne eliminovat.

[Petr Mach]

Nikdo ti nic nediktuje. Naopak, ty chces vyvojarum diktovat, jake maji pouzivat knihovny a cfg. soubory.

jak vidim, nejste schopen pochopit a to, ze clovek upravuje konfiguracni soubor manualne v libovolnem textovem editoru podle sve volby, je zrejme odporny prezitek

To vidis blbe, ja cfg. soubory upravuji zrovna a prave tak. A kupodivu, Elektra ti umozni i tento pristup k cfg. souborum, ale krome toho ti umozni i jine pristupy, ktere ted mozne nejsou vubec a nebo jen stazi. Elektra tak nabizi vetsi flexibilitu prace s cfg. soubory.

A jestli jedine co si dovedes predstavit je ubijejici manulani konfigurace v textovem editoru, prestoze by bylo mozne a zadouci tuto cinost zautomatizovat, pak skutecne obhajujes lidsky tupy pristup windows.

[unchallenger]

Ten jsem navrhl -- programy samy budou poskytovat jednotné rozhraní pro jednoduchou konfiguraci, každý pro svou. Složitou konfiguraci (bashrc, sendmail) Elektra nezjednodušuje, ale komplikuje, tudíž mohu vymyslet něco jiného, co ji bude také komplikovat, avšak považuji to za plýtvání silami.

[Petr Mach]

Tomu nerozumim. Jake rozhrani budou programy poskytovat, jak toto rozhrani bude vypadat? Bude jejich soucasti i nastroje pro praci s cfg. soubory z prikazove radky a api pro jejich pouzivani z ruznych programovacich jazyku?

Proc by toto rozhrani nemohla zajistovat u nekterych programu treba Elektra? Vyvojari techto programy by totiz vyse uvdene nemuseli resit.

Elektra konfiguraky nezjednodusuje, z principu ani nemuze. Ale zjednodusuje praci s nimi, a to zbytecne plytvani silami neni.

[Hynek (Pichi) Vychodil]

Je to málo flexibilní, pomalé, náročné na systémové prostředky, zbytečná práce navíc a hlavně: Nic to nepřináší! Tohle už to bylo tisíckrát.

[Petr Mach]

1) Co je na tom neflexibilniho?

2) Co je na tom pomaleho? Delal jsi nejake testy?

3) Jake to ma naroky na systemove prostredky? Zajimaji me konkretni udaje.

4) Praci to naopak setri. Predstav si admina, ktery ma upravit jednu polozku cfg. souboru na stovce pocitacu. Dejme tomu zmenit cestu adresare s fonty.

5) Zde se mylis, prinasi to naopak hodne, prinasi to snadnou neinteraktivni (automatickou) praci s cfg. soubory tretim stranam. Napr. snadna zmena konfigurace z prik. radku nebo skriptu.

Zkus se najdriv zamyslet nad svym silnym tvrzenim .

[unchallenger]

Ještě si neodpustím jednu poznámku: jak si představují, že přimějí tvůrce distribucí přejít na tohle, když je, jak sami přiznávají, zatím nikdo nepřiměl ani k jednotnému nastavení hostname.

[unchallenger]

K $SUBJ už nám fakt chybí akorát metametamoderace a odkazy na goatse.cx...

[Leoš Literák]

Elektra mi pripomina properties z Javy, Jednoduche a rychle, lec se slabou vyjadrovaci schopnosti, Tudiz pouzitelne jen malokde. Oproti tomu s XML s rozumne definovanym DTD (nebo primo schematem) dokazete popsat prakticky cokoliv. Viz treba porovnani konfiguracnich souboru Jakarta LOG4J (prejmenovano na Apache Logging), s log4j.properties se bez manualu citim ztracen, s log4j.xml mi nazvy elementu napovi. A zanorovani je zase logicke, takze nemusim hledat, k cemu dany klic patri (viz problemy elektry vyse).

Vhodne navrzene XML je urcite cesta vpred. (ted nepisu o elektre)

1. Umozni automatickou validaci - jak treba dnes zjistite, ze mate v nejakem konfiguraku formalni chybu?
2. Zjednodusi vyvojarum aplikace nacitani/zapisovani konfigurace
3. Umozni jednodussi vytvareni aplikaci tretich stran (metakonfiguratory typu Yast ci Webmin)
4. Zustava editovatelne na urovni textovych souboru

XML pouzivam kazdy den, jako vyvojar i admin. Spousta nastroju ci aplikaci je v XML. Kdyz potrebuji neco zmenit na abicku, pres ssh se pripojim, spustim VI a upravim, co potrebuji.

Nicmene XML ma take dost nevyhod. Napriklad ve chvili, kdy potrebujete zadat nektere znaky typu mensitko ci vetsitko, stava se vypis dost neprehlednym. At uz kvuli CDATA sekci nebo kvuli entitam. Dalsi nevyhodou je ukecanost. Ona je tedy vyhodna, kdyz ctete XML (jak jsem jiz zminoval vyse), ale kdyz neco zapisujete, muze byt docela otravna. Zkuste si treba predstavit crontab v XML Dalsi nevyhodou je urcita vypocetni a pametova narocnost pri zpracovani.

Holt vse ma sve klady a zapory. A IMNSHO klady u XML prevysuji.

[Michal Marek (twofish)]

Zkuste si treba predstavit crontab v XML

Mně přijde zbytečné ukládat jakoukoliv tabulku do XML. Nevíte někdo o nějakém validačním schématu (klidně se zápisem v XML ) pro CSV (oddělovač, typy sloupců, povinné/nepovinné sloupce, různé druhy řádků, komentáře, ...)? Potom by XML ztratilo oproti normální tabulce IMHO jedinou výhodu snadné validace.

[Michal Marek (twofish)]

Podle http://freedesktop.org/Standards/config-spec to vypadá, že Elektra padne za oběť přirozenému výběru. Takže co vlastně řešíme...

[VícNežNic]

To stejně. Začínám pomalu žasnout nad čím tu lidi dokážou strávit víkend.

Elektra (skutečně hnusné jméno) ani cokoliv jiného podobného vyžadující aktivní spolupráci autorů všech programů a distribucí nemá v následujících minimálně dvou až tří letech moc šancí. Vidíte to sami, koneckonců.

A největší odpůrci už pomalu pokládají nálože (fšecky nás odpadlíky elektrácký smetou) a připravují se k ústupu na BSD

[jm]

Krasna signatura... Spravila mi naladu.

[Petr Mach]

Vyborne, to je jeste lepsi nez Elektra . Tedy ideove, uvidime jak vsechny ty rquirements dohromady dokaze nekdo implementovat, zvlaste s temi "Useful bonus features", to se mi zda az technicky nerealizovatelne. A bez "Useful bonus features" nam vzniknou sitove registry windows.