Tlačítka v Ubuntu zůstanou vlevo

WebUpd8.org informuje, že Mark Shuttleworth oznámil konečné rozhodnutí ohledně tlačítek pro ovládání oken v Ubuntu Lucid Lynx. Tlačítka zůstanou na levé straně, změní se však jejich pořadí na „zavřít“, „minimalizovat“ a „maximalizovat“.

2.4.2010 10:53 | Tomáš Heger (geckon) | Komunita

Komentáře

[Tomáš Peroutka]

Linuxová komunita mi do značné míry připomíná politickou situaci v ČR...

[sssssssss]

nekdy tak, nekdy anarchii, nekdy komunizmus

[kyytaM]

V pripade Ubuntu mi na um prichadza len koko**zmus. :/

[Lukáš Zapletal]

Jenže do businessu a na miliony desktopů jinak neprorazíte.

A to si strašně moc linuxáků bohužel neuvědomuje. A já to na druhou stranu chápu.

[imploder]

Takže když necháme tlačítka tam, kde je doteď všechny normální linuxy a windowsy měly, do bussinessu a na miliony desktopů neprorazíme? To spíš naopak, tohle lidi ještě víc odradí.

[newman]

To je sice mozne, ze ti tyhle dva smery pripominaji, ale pletes se.

Komunity jednotliveho daneho projektu nejsou anarchisticke, protoze maji hierarchicke struktury (napr. ne kazdy muze commitovat), ani nejsou komunisticke, protoze ac kazdy muze dany kod "vlastnit", ve smyslu "mit u sebe a jen pro sebe", tak s nim nemuze nakladat libovolne (treba zmenit jeho licenci, protoze autorske pravo).

Projekty a komunity jsou spise hierarchicke meritokracie s prvky formalni demokracie. Ale to je jen ma domnenka, k precteni serioznejsiho vyzkumu jsem se nikdy nedostal.

[mmn]

nejsou komunisticke, protoze ac kazdy muze dany kod "vlastnit", ve smyslu "mit u sebe a jen pro sebe", tak s nim nemuze nakladat libovolne (treba zmenit jeho licenci, protoze autorske pravo).

Já bych právě řekl, že z tohoto důvodu komunistické jsou -- i komunismus musí mít svá pravidla nakládání s (výrobními) prostředky.

Projekty a komunity jsou spise hierarchicke meritokracie s prvky formalni demokracie.

S tím se dá vesměs souhlasit.

[vain]

Linuxová a Ubuntu komunita je dost velký rozdíl, neplést si!

[corwin78]

A v čempak se tyto "dvě" komunity liší, poučte mě? Já myslel, že všichni používáme GNU/Linux.

[vain]

Já myslel, že všichni používáme GNU/Linux.

Řekl jsem snad že ne? (pominu-li uživatelé co tady chodí a používají třeba BSD apod..). Možná by neškodilo si přečíst vlákno znovu a přeformulovat otázku, respektive ten dovětek.

[corwin78]

Opravdu? Spíš bych řekl, že by jste si to vlákno měl přečíst vy a k tomu i vlastní komentář. V příspěvku, na který jste reagoval se hovoří pouze o Linuxové komunitě a vy, ve vašem příspěvku srovnáváte výhradně Linuxovou a Ubuntu komunitu, proti čemuž jsem měl výhrady.

[vain]

Ne, já nikoho nesrovnávám, to bude asi ten zásadní rozdíl. A když tedy v tom rozdíl není (v Ubuntu a GNU/Linux komunitě) tak hodně štěstí s tlačítky na levé straně.

[corwin78]

Děkuji za přání, ale mě se tato změna netýká, používám KDE Peace...

[vain]

No a já nepoužívám Ubuntu a tedy se mě to taky netýká - o tom jsem ostatně mluvil že =)

[Tomáš Peroutka]

Já si je taky nepletu :c) Já přirovnávám celou Linuxovou komunitu k naší politice. Nikoliv Ubuntu k ČSSD Vždyť aj v naší politické situaci existují pravicové strany. Jen je stále více slyšet o převaze těch levicových (a přechodu středových k levici)

Ha, politika!

[vain]

Ha, politika!

Jen tu tady prosím netahej =)

[xkucf03]

On to stejně nakonec vyřeší trh. Nabídka se střetne s poptávkou a lidi si zvolí takové téma vzhledu, které jim vyhovuje.

[omegan]

ja som presiel z linuxu na win 7 a som spokojny. Po 15 rokoch marneho cakania na normalnu linuxovu distribuciu som presedlal na windows. Zatial vsetko funguje.

[vain]

Já už slyšel hodně blbostí, ale toto... Srovnávat Windows s distribucí Linuxu...

[default]

Podle mě to žádná blbost nejni. Jediný, čím se Windows od Linuxových distribucí liší, je dostupnost a distribuce software třetích stran. Zatímco v Linuxu máš správce balíčků, který to tahá z internetu a stará se o aktualizace, na Windows si to musíš (pravděpodobně) řešit sám. Další rozdíl je dostupnost komerčního software.

[vain]

Do téhle diskuse nejdu, těch věcí je mnohem, ale opravdu mnohem více. Ale debata přes komentáře o tomhle by byla pomalu na nekonečno, takové věci jedině ústně u piva nebo láhve tequily pokud jde o mě =) Ale opravdu jsem se nerozhodl používat GNU/Linux jen kvůli balíčkovače v distribuci (i když to je opravdu dnes už pro mě nepostradatelná věc), je toho opravdu mnohem víc, proč jsem přesedlal na GNU/Linux a vzhledem k tomu, že v práci se denně setkávám na stanicích s Windows jakožto správce IT techniky, tak jsem jen rád za to, že mám možnost ne jen doma, ale i v práci používat Linux, a nikdy bych tyto dva operační systémy nesrovnával, oba mají dost daleko do sebe navzájem, každý má něco do sebe, ale jsou nesrovnatelné.

[Dent]

No aspoň že tak, to je logičtější než minimalizovat, maximalizovat a zavřít. Na levé straně jsem z tohoto rozvržení rostl. Ještě aby na levou stranu přesunuli scrollbary a bylo by to super - komplet ovládání na levé straně (menu, okna, scrollbary). Jako pravákovi mi to přijde mnohem lepší.

[Jakub Lucký]

Já jsem si po prvním zveřejnění téhle eskapády ty tlačítka úplně zrušil... A docela dobrý...

[tmr]

Jakej to ma vlastne duvod, to presunuti?

[m1c4a1]

To už tady kdysi bylo... možná půjdou na pravou stranu reklamní bannery, tlačítka pro Paypal apod.

[tmr]

:D

Ale fakt tohle nechápu - proč to dělat, když je proti drtivá většina uživatelů. Lidi si neradi zvykají na nové věci, proto jsou dobře neoddůvodněné změny a obecně nekonzistence chyby v použitelnosti. Poslední dobou dost uvažuju o přechodu k Win7 popř. k Macu :( ...

[Majkii]

no nema to bejt prave jako u macu? obecne mi ubuntu prijde cim dal vic jako mac os x... os x ma totiz tlacitka vlevo

[imploder]

V ubuntu jsou v jiném pořadí.

[tomasgn]

ubuntu se zrejme snazi byt nekompatibilni s cimkoliv jinym.

[tmr]

Vim ze to ma Mac taky vlevo, ale obecne je Mac mnohem pouzitelnejsi OS (proto uvazuju o prechodu). Bohuzel free software zdarma nema moc sanci uspet na poli desktopu - kokurence ma proste mnhoem vice prostredku a muze se vice zamerit na urcite cile (narozdil od chaoticnosti free softwaru). Microsoft a Apple si mohou dovolit tymy, ktere testuji a vylepsuji pouzitelnost, grafiku, opravuji bugy (Win7 ma napr. tak o rad min bugu nez jakakoliv Linuxova distribuce) atd. Jestli se Linux vice rozsiri na desktopy, tak to bude ve forme Chrome OS.

[imploder]

Chrome OS není desktopový OS, jak ho běžně chápeme, je to jen jakési osekané prostředí s linuxovým jádrem, kde běží prohlížeč. Výhodu to má, že rychle startuje, ale jinak je to prostě systém zaměřený čistě na používání webu. Takový odlehčený OS na provozování věcí od Googlu. Plnohodnotná náhrada Windowsu nebo Linuxu to rozhodně není, navíc všechny ty jejich aplikace se samozřejmě dají používat i v normálním Linuxu nebo Windowsu. Takže pokud chci Linux, nevidím žádný důvod instalovat si místo normálního distra nějaký "bootovací prohlížeč" od Googlu, pokud teda nepotřebuju nutně, aby to rychle naběhlo.

Mac má hlavně výhodu, že je to jeden hardware a OS pro něj může být perfektně odladěný, na PC se prý zprozovnit taky dá, ale za moc to nestojí (rozhodně to není "works-out-of-the box" jako u HW Applu). Jejich HW je podle parametrů předražený, ale zase třeba ty notebooky vydrží na baterku 7 hodin (asi taky výsledek dobrého sladění HW a SW) - takže záleží, jak se to vezme.

[tmr]

Ale Chrome OS ma potencial stat se plnohodnotnou nahradou. Bud umozni instalaci nativnich aplikaci nebo se webove aplikace stanou srovnatelnme s desktopovymi. Tipnul bych si ze pro vetsinu lidi je prohlizec nejpouzivanejsi aplikaci. Napr. ja krome prohlizece pouzivam jenom Eclipse, Totem na filmy a spravce souboru. Dokazu si predstavit, ze za par let si vystacim jenom s prohlizecem.

[frdrx]

Nemá, nestanou.

[tmr]

No uvidime...

[frdrx]

(Win7 ma napr. tak o rad min bugu nez jakakoliv Linuxova distribuce)

Vista 7 je sama jeden velký bug. Mimochodem, skoro jakákoli distribuce toho umí o řád víc než Windows, takže srovnání absolutního počtu bugů vůbec nic neříká, a to i kdyby ty Windowsácké byly sledovány veřejně.

[otula]

(Win7 ma napr. tak o rad min bugu nez jakakoliv Linuxova distribuce

Lež. http://secunia.com/advisories/product/27467/?task=statistics_2010 http://secunia.com/advisories/product/339/?task=statistics_2010

[tmr]

Myslel jsem to tak, ze podle subjektivniho dojmu je Win7 min "zabugovanejsi". V Ubuntu musim neco resit/nastavovat mnohem casteji, ve Win7 mi vsechno tak nejak funguje bez nastavovani.

[Sešívaný]

Tak používej distribuci, která má vývojový cyklus aspoň tři roky, např. RHEL. A uvidíš, že je o řád stabilnější než Windows. Kdyby byly Windows vydávány každého půl roku, to bychom se ještě pobavili. Prostě je potřeba srovnávat srovnatelné.

[tmr]

Tak ty jine distribuce maji zase jine nevyhody...

[Sešívaný]

Stejně tak Windows mají své nevýhody, ideální systém prostě neexistuje, vždy je to otázka kompromisu a osobních preferencí.

[Matlák]

A jaké nevýhody? Že to není barevné a gumové jako Ubuntu? Že to má ostré hrany, a nedá se to oslintávat? Neříkej "jakákoliv linuxová distribuce" když myslíš ubuntu. A beztak je to srovnání naprostej blábol.

[Filip Jirsák]

Microsoft a Apple si mohou dovolit tymy, ktere testuji a vylepsuji pouzitelnost, grafiku

Otázka je, zda to není kontraproduktivní. V poslední době mám pocit, že jakmile je někde napsáno „vylepšená použitelnost“, „navrženo odborníky na ergonomii“ nebo něco podobného, znamená to, že to skoro nepůjde používat (např. souborové dialogy GTK, MS Office 2007…)

opravuji bugy

„O problému víme, záplata zatím není k dispozici.“

Win7 ma napr. tak o rad min bugu nez jakakoliv Linuxova distribuce

Také mají o několik řádů méně programů.

[tmr]

Otázka je, zda to není kontraproduktivní. V poslední době mám pocit, že jakmile je někde napsáno „vylepšená použitelnost“, „navrženo odborníky na ergonomii“ nebo něco podobného, znamená to, že to skoro nepůjde používat (např. souborové dialogy GTK, MS Office 2007…)

Urcite to neni kontraproduktivni, celkove jsou na tom Win7 co se tyce pouzitelnosti mnohem lepe, napr. hlavni lista/start menu. Konec koncu i ty Office 2007 jsou pouzitelnejsi nez OpenOffice (ktere se inspirovali u starsich Officu). Problem s Office 2007 je, ze je rozhrani uplne predelane, takze si uzivatel musi nejakou dobu zvykat.

„O problému víme, záplata zatím není k dispozici.“

Mam na mysli spis takove bugy, jako ze mi nefunguje uspavani, v Eclipse nereaguji tlacitka na stisk, nefunguje flash atd. Win7 mi proste prijdou odladenejsi.

Také mají o několik řádů méně programů.

Viz komentare vyse.

[Filip Jirsák]

Problem s Office 2007 je, ze je rozhrani uplne predelane, takze si uzivatel musi nejakou dobu zvykat.

Rozhraní, na které si člověk nezvykne ani po dvou letech, je podle mne k ničemu.

Mam na mysli spis takove bugy, jako ze mi nefunguje uspavani, v Eclipse nereaguji tlacitka na stisk, nefunguje flash atd. Win7 mi proste prijdou odladenejsi.

jestli to nebude tím, že ve Windows 7 Eclipse ani Flash nejsou…

[tmr]

Rozhraní, na které si člověk nezvykne ani po dvou letech, je podle mne k ničemu.

Spousta lidí si zvykla...

jestli to nebude tím, že ve Windows 7 Eclipse ani Flash nejsou…

To s tim Eclipse byl bug v GTK, coz povazuju za soucast OS. Flash - ok souhlasim...

[Marián Kyral]

Rozhraní, na které si člověk nezvykne ani po dvou letech, je podle mne k ničemu.

Spousta lidí si zvykla...

Jo jo, proto to MS v nové verzi zase změní

[xkucf03]

Jak souvisí uzavřený proprietární Flash s Linuxem? Copak má někdo od Linuxu nebo z FOSS komunity moc jeho chyby opravit? Mně taky Flash nefunguje (zadávání českých znaků), ale jediný, komu bys za to mohl nadávat, je Adobe.

[tmr]

FOSS komunita za to nemuze, na druhou stranu chapu Adobe, ze dava vice penez na vyvoj na verzi pro Windows. To, ze jsou Windows tolik rozsirene prinasi pro jeho uzivatele pochopitelne vyhody.

[vain]

Win7 ma napr. tak o rad min bugu nez jakakoliv Linuxova distribuce

Nějaký odkaz na statistiky? Počet bugů u Windows 7 atd..? Nebo jen "fakta" vycucána z prstu? Tvůj komentář by měl obsahovat tak minimálně pět odkazů podporující tvá tvrzení, jinak se jedná o totální hovadinu, za kterou tvůj komentář momentálně považuju.

[tmr]

Je to vycucane z prstu, jenom muj osobni dojem, viz komentar vyse.

[vain]

Aha, takže na kidy na internetu reaguješ jinými kidy... pak že diskuse nevypadají tak, jak vypadají, všichni mají své "zaručené fakta".

[tmr]

Nejsou to kidy, jenom jsem se spatne vyjadril, mel jsem dat vice najevo,ze to je osobni dojem a ne 100% objektivni informace.

[Pavel Beníšek]

To jsi pak musel vyjadrit uplne neco jineho. Protoze pocet bugu jinak nez objektivne hodnotit nelze.

[tmr]

Myslel jsem pocet otravnych bugu na ktery narazim.

[Jirka]

- Dovolte, abych vám představil svoje spolupracovníky: Kojot Kid, Pancho Kid.
- Nestojím o vaše kydy.

[TM]

I se skromnymi prostredky lze udelat kvalitni produkt. Svincik v linuxovych distribucich neni dan nedostatkem penez, ale samou podstatou vyvojoveho modelu - nikdo za nic nezodpovida, kazdy si dela co chce...neustale se ve vsem vrtaji "zlepsovatele", kteri nemaji tuseni o tom, co uzivatel potrebuje. Ubuntu sice nepouzivam, ale pokud Canonical vnese do te veci trochu radu i za cenu urcitych konfliktu a kontroverznich rozhodnuti, bude to zasluzny cin.

[Martin Mareš]

"zlepsovatele", kteri nemaji tuseni o tom, co uzivatel potrebuje

Zatímco u jiných systémů jsou si výrobci proklatě jistí tím, co uživatel potřebuje. Jen ani jedni, ani druzí se nejspíš nikdy žádného uživatele nezeptali ;)

[TM]

Zkušenosti z praxe hovoří zcela jasně. Komerční GUI 2 velkých firem uživatelům nečiní velké potíže a víceméně prostě fungují - koordinovaný a cílevědomý vývoj je znát. GUI na Linuxu je dnes pro uživatele spíše za trest. Vedle nesmyslných "zlepšováků" o které nikdy nikdo nestál, je vidět i bohužel příšerně nízká kvalita - neotestovaný, nedodělaný produkt, který bývá po krátké době nahrazen dalším nedodělkem.
Těm velkým firmám vůbec nefandím, ale realita je realita. Linuxové distribuce dnes ve srovnání s komerční konkurencí uživatelům nabízejí jakousi obdobu zboží z Vietnamské tržnice, nikoliv kvalitní prostředí pro bezproblémové používání. Z toho chaosu kolem desktopu ani nic lepšího vzniknout nemůže - problém je v tom, že firmy RedHat i Novell daly od desktopu ruce pryč a bez firemní kultury takto velká věc prostě kvalitně dělat nejde...

[vain]

Microsoftu to nejde ani tak, Linux je na tom ještě dobře, nedám na něj ne jen na desktopu dopustit. A navíc o jakém GUI je jako řeč? Drtivou většinu aplikací, které používám používají lidé i na Windows, takže mi to nějak nesedí co je na něm špatného, a kdo ho má vlastně lepší?

[Sešívaný]

Např. na GNOME pracuje Novell a Red Hat ve velké míře. Prakticky všechny důležité věci tam dělají placení lidi s tou vaší firemní kulturou. GUI Windows je tak promakané, že když v něm musím dělat, tak bych si nejraděj vydrápal oči a moje mamka za mnou sama od sebe přišla, jestli bych jí na nový notebook místo Windows nenainstaloval Ubuntu, že jí to prostředí přijde hrozně chaotické.

[imploder]

pokud Canonical vnese do te veci trochu radu i za cenu urcitych konfliktu a kontroverznich rozhodnuti, bude to zasluzny cin

Canonical nesmyslným šachováním s ovládacími tlačítky akorát vytváří další bordel a že takový přístup lidi odmítají (je "kontroverzní") je zcela na místě.

[me]

Ale ta zprávička, která to uváděla, byla z kategorie Humor...

[imploder]

Bylo to ze sekce humor, to co se tam plánuje doopravdy je minimálně stejně ulítlé: http://lwn.net/Articles/380594/

A tohle - ovládání ve stylu "hádej co ta koule dělá" - už je myšleno vážně. Když už, tak v MS vymysleli do rohu okna něco zábavnějšího než nějaká divná koule: http://www.abclinuxu.cz/zpravicky/tajne-plany-na-vyuziti-okenni-dekorace-v-ubuntu/diskuse#34

[otula]

Příloha:

• dekorace.png (19336 bytů)

Zeptám se blbě: Správce oken v Gnome neumožňuje něco takového? (viz přílohu)

[otula]

…a vždy je tu ještě možnost použít například Openbox (nemyslím celé prostředí, ale jen správce oken). Já si ho nemohu vynachválit.

[maor]

... alebo radikálne zmeniť celé prostredie. Nové Xubuntu nevyzerá až tak zle.

[Jardík]

Umožňuje, jenže to nejde nastavit v tématu (v KDE tuším, že se to dá nastavit v tématu a uživatel může tuto volbu "přebít"), ale natvrdo v gconfu pro všechny témata: /apps/metacity/general/button_layout

Arrangement of buttons on the titlebar. The value should be a string, such as "menu:minimize,maximize,spacer,close"; the colon separates the left corner of the window from the right corner, and the button names are comma-separated. Duplicate buttons are not allowed. Unknown button names are silently ignored so that buttons can be added in future metacity versions without breaking older versions. A special spacer tag can be used to insert some space between two adjacent buttons.

[Quentin]

Nastesti to jde docela jednoduse upravit, takz epo donistalovani pidgina, zmenu vychoziho prohlizece si ted jeste budeme muset upravit tlacitka.... Zde je odkaz na upravu: http://www.webupd8.org/2010/03/mwbuttons-complete-gui-for-customizing.html

[Václav Kramář]

Ne tak docela. Protože používají taky atypický pořadí, tak si budeš muset taky zvolit jiný Metacity téma. Jinak to bude vypadat strašně. Samozřejmě za předpokladu, že si to vrátíš 100% do obvyklého stavu. Komu nevadí změněné pořadí ikon, ten se asi smíří i s jejich jinou polohou.

Kdo používá jenom Ubuntu, pro toho je to jenom otázka zvyku. Kdo ale střídá víc systémů, ten bude nešťastný. A nemusí to být ani žádný distribuční turista - stačí, že má něco jiného v práci.

[Quentin]

To si nemyslim, podle te utilitky, jenz jsem zminil vyse si vyberes i poradi a vypada to normalne....

[Václav Kramář]

Věř mi. Zkoušel jsem to.

[Quentin]

OK, nebudu to rozporovat,kazdopadne pro ostatni,ja to mam a funguje to...

[imploder]

Je otázka, jestli vůbec nastavení tohohle typu patří do tématu. Téma nenastavuje rozmístění ovládacích prvků (umístění lišty, apletů atd.), nastavuje jenom vzhled. Takže ani tohle do něj logicky asi nepatří.

[Jardík]

Jenže téma jako takové, co je teď v ubuntu, kdy je za tlačítkama ten "důlek", může být na rozmístění tlačítek závislé a samozřejmě by to mělo být v tématu možnost nastavit. Samozřejmě by tu ale měla být možnost takové nastavení potlačit a nechat si to svoje, na svoje vlastní riziko.

[srigi]

Tusim tu na ABC som cital, ze v mailingliste su az 2/3 nesuhlasnych nazorov. Toto je teda krasny odkaz od MS, ze nazor jeho uzivatelov mu je celkom ukradnuty.

Uz vidim tie tisice "preklepov", ked user pojde na menu FILE a zavrie si pritom program. Ako uz niekto spominal, v MAC OS ma tento layout logiku, lebo menu je top bare obrazovky. Ubuntu iba sprosto kopiruje, bez pouzitia stipky rozumu.

[xhombre]

Ale no tak, to by ten uzivatel musel byt ale kurva levak.

Jen tak jsem to na notesu nechal (a to na desktopu pouzivam arch s awesome) a za celou dobu ani jeden preklep. Manzelka taktez. Nedelejme z komara velblouda.

Treba ve workbenchi to bylo uplne jinak a take jsem si na win a pak linuxu zvykl.

[xhombre]

Mimo to ma jistou logiku mit ovladani oken vlevo kdyz uz tam je ovladani prakticky vseho.

[Pajinek]

Tak nevím jestli to tu padlo, ale osobně mám tlačítka na levé straně už dlouho, ale o to nejde. V ubuntu je poměrně snadné si tlačítka přizpůsobit na jakoukoliv strana a pořadí jak kdo chce. Tady je postup

Otevřeme gconf-editor (Atl + F2, do políčka napíšeme gconf-editor). Vlevo postupně rozevíráme apps – metacity – general a vpravo pak dvojklikem otevřeme editaci klíče button_layout – hodnotu změníme na menu:minimize,maximize,close. (převzato http://blog.quimi.cz/item/ubuntu-10-04-zatim-spise-rozpaky)

znak ":" odděluje pravou stranu od leve.

[tomasgn]

bohuzel me tohle hrani s gconf-editorem az prilis pripomina jiz temer zapomenutou onanii s windows registry

po katastrofe zvane KDE4 dochazi ke zprzneni dalsiho desktopoveho prostredi. fakt diky osvicenemu Markovi, ze nam vnucuje svoji zajiste skvelou predstavu o linuxovem desktopu. doufam, ze to neprosakne i do dalsich distribuci, alespon v tom rozsahu, ze to nebude default a zmena nebude vyzadovat boj s odpornym gconf-editorem.

[kkaarreell]

bohuzel me tohle hrani s gconf-editorem az prilis pripomina jiz temer zapomenutou onanii s windows registry

Tohle narikani me vzdycky dostane. Pamatuju dobu, kdy se autori jakekoliv klikaci utility setkali s odporem, protoze "klikani je pro lamy, tohle preci jde tak snadno nastavit v konfiguraku". Naopak KDE oproti GNOME boduje, protoze umoznuje spoustu veci nastavit (rozumnej naklikat) a "neomezuje" uzivatele (rozumnej uprava gconf je si nad sily prumerneho linux hackera). Tuhle schizofrenii jsem nikdy nepochopil. Nerad bych se dotkl uzivatelu KDE, at si kazdy pouziva to, co mu vyhovuje. Osobne ale veci nastavuji jednou, typicky po instalaci (a je mi temer jedno jestli to naklikam, prepisu konfigurak ci spustim nejaky prikaz). Muj bezny pracovni den ma jinou napln, nez neustale meneni nastaveni v KDE/GNOME. Proto je mi prakticky jedno, co za prostredi pouzivam. Btw, ten tvuj boj predstavuje spusteni jednoho prikazu z terminalu. To by uzivatel Slackware zvladnout mohl.

[default]

Problém je, že tohle se nakliká, tohle se udělá tady v tom konfiguráku v tomhle formátu, tohle zase v v jiným konfiguráku támhle v jiným formátu; a jestli jste nezapomněl oeditovat táhleto, pak ještě tady, tady, tady a tady. Jak Škoda Henlein.

Jako se zajedly koncetráky, konfiguráky se zají taky. Ve Windows je to sjednoceno aspoň na ty registry, zbytek jsou INI soubory.

"Zdokumentované" je to oboje stejně — Google.

[l4m4]

zbytek jsou INI soubory.

Které, takto chytře pojmenovány, náhle přestanou být konfiguáky rozstrkanými po desítkách nelogických míst ;)

Největší mor jsou binární konfigráky, v těsném závěsu následovány zneužitým XML, Naneštěstí si autoři některých linuxových programů zřejmě v tomho ohledu dali za cíl dohnat a předehnat...

[default]

Já měl na mysli formát. Nikoli jejich počet.

[l4m4]

Pominu-li naprosté úlety jako konfigurák sendmailu, tak se syntaxí není problém. Jednou je třeba napsat rovná se, jindy ne, nebo se něco někde dává do uvozovek a jindy ne. Katastrofa.

Ale především unixové konfigiráky slušných programů v sobě mívají komentáře s popisem, co do nich lze napsat, jak to napsat a příklady, pěkně v místě, kde je třeba ty věci napsat. Takže otevřu konfigurák, přečtu si komentář a upravím konfiguraci, aniž bych toho nosil hromady v hlavě.

Které windowsí programy mají takhle pěkně upravovatelné INI soubory? Jak zjistíš, jak máš zapsat netriviální hodnotu (tj. typu výraz, maska, pravidlo, ne boolean nebo integer) v INI souboru?

Jednotná základní syntaxe je sama o sobě naprd, k čitelnosti a editovatelnosti pro člověka jsou třeba jiné vlastnosti (což zjevně nechápou ani XMListi).

[Filip Jirsák]

Konfigurák v XML může mít tu dokumentaci v XML schématu, takže vám ji může editor zobrazovat také, ale navíc může hlídat, zda do číselné hodnoty píšete opravdu číslo, nebo může nabízet seznam přípustných hodnot tam, kde je výčet. To mi připadá lepší, než komentář, kterému rozumí jen člověk, ale editor ne.

[xkucf03]

Příloha:

• xml-konfigurák.png (195358 bytů)

+1 pro názornost přikládám obrázek, aby si to xml-skeptik dokázal představit

Bohužel hodně lidí si pořád myslí, že XML jsou jen špičaté závorky a ukecaná syntaxe, ale často nevědí o těch technologiích nad tím.

[xkucf03]

Co je na XML konfigurácích špatně?

[Filip Jirsák]

No přece že si nemůže každý program použít svůj specifický jazyk pro konfigurační soubory a autor toho programu si nemůže napsat svůj vlastní parser toho konfiguráku. A pak se další spousta lidí nemůže věnovat tomu, aby napsali zvýrazňování syntaxe pro různé editory…

[default]

[default]

Abych byl Amigapower complient: měl jsem co dělat, abych si nezamotal péro do kabelu od sluchátek. (Je to spirálovitý kabel, dohledej sám, šmudlo, Xone XD53).

Abych byl default compliant: na XML konigurákách je špatně to, že každej používá svoje schéma nebo DTD, který je nekompatibilní s default's XMLSchema.

Current track: Chris Standring — All In Good Time

[default]

Current track: Chris Standring — All In Good Time

Nakoupíte v nejbližším iTunes Store. (Abych si rejpnul )

[default]

Apple je nejlepší, protože má tlačítka nalevo.

Linux je nejlepší, protože na něm běží Oracle Database 11gR1 a Oracle Database 11gR2.

[default]

A teď už se fakt musim jít balit, jinak mi to zejtra uletí. Od toho letadla jsou, né?

[default]

Tu historku o explosves raději vynechám.

[Algi]

S tím Oracle je to dost trefná poznámka. Ale je fakt, že ono nainstalovat 10g na Mac byl takový humus, že jsem to v půlce vzdal. V tomhle směru zlaté PostgreSQL. Jednoduchá instalace a pro mé potřeby identická funkcionalita. V tomhle směru obrovské mínus pro Oracle.

Jo a sorry, že ti tu kazím tvůj MONOlog

[default]

S tím Oracle je to dost trefná poznámka. Ale je fakt, že ono nainstalovat 10g na Mac byl takový humus, že jsem to v půlce vzdal. V tomhle směru zlaté PostgreSQL. Jednoduchá instalace a pro mé potřeby identická funkcionalita. V tomhle směru obrovské mínus pro Oracle.

Já to ani neměl chuť zkoušet. Dovedu si představit, že by to skončilo reinstalací OS X. Oni jsou hoši od Oracle tak trošku prasata, když se člověk podívá dovnitř. Třeba takový Enterprise Manager, to je síla! Jestli budou v tomhle stylu dělat Javu, tak nevím, nevím.

Jo a sorry, že ti tu kazím tvůj MONOlog

Nic se neděje. Zase za rok.

[xkucf03]

A jak by sis představoval obecné DTD/Schéma obecně použitelné pro všechny aplikace? Je něco takového vůbec možné?

[l4m4]

Co je na XML konfigurácích špatně?

Čitelnost a editovatelnost pro člověka je mizerná. A ukaž mi nějaký pěkně okomentovaný XML konfigurák s poznámkami, který zároveň funguje jako svoje dokumentace.

[Filip Jirsák]

Máte nějaký lepší formát konfiguráku? Myslím pro složitější konfiguraci, nemluvím o případech, kdy se v konfiguráku zadají celé tři hodnoty. Podle mne jakýkoli takový formát nakonec bude jenom XML s jinými závorkami. Jenže pro XML už je tady spousta nástrojů a standardů, které se dají využít. Okomentovaný konfigurák třeba zde, ovšem je tam špatná struktura XML, protože se to mapuje přímo na volání metod, místo toho, aby se skutečně využilo XML.

[l4m4]

Pointa věci je, že pro každý jednotlivý problém existuje odlišná optimální represetnace. V řadě případů asi dost exotická (viz např. procmail, kde byla syntaxe konfiguráku zjevně vedena optimalizací pro konkrétní problém), tudíž se volí jakýsi kompromis mezi vhodností a obecnou srozumitelností. Zvýší použití XML vhodnost pro konkrétní úlohu? Zvýší srozumitelnost? Uvidíme dále...

Podle mne jakýkoli takový formát nakonec bude jenom XML s jinými závorkami. Jenže pro XML už je tady spousta nástrojů a standardů, které se dají využít.

Ve skutečnosti je to naopak. Cokoli lze samozejmě zapsat do XML, když to kreativně olepím špičatými závorkami. Ale XML není syntaxe toho konfiguráku, to je až příslušné schéma, XML je zde pouze serializační formát (IMO dost nepraktický). Ovšem potom padá tvé tvrzení o nástrojích, protože na editaci obecných textových souborů mám taky nástroje. Jak textové nástroje, tak XML nástroje pracují pouze na úrovni serializačního formátu, nikoli na úrovni konfiguráku. Uznávám, že pro XML existují validační nástroje, jenže abychom je mohli použít, je třeba mít schéma, které za něco stojí...

A konečně, representace v XML je iluze. Chci representovat např. tento jednoduchý segment ssh_configu:

Host *.muni.cz
   SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
   ...

Pak mohu udělat, jak se typicky dělá:

<Host pattern="*.muni.cz">
   <SendEnv>LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES</SendEnv>
   ...
</Host>

Ale co nám tam dělá to *.muni.cz a ten seznam v SendEnv? To je pořád ne-XML syntaxe, akorát zabalená do XML, takže teď tam mám pořád ad-hoc syntaxi, a navíc se to celé zamatlalo špičatými závorkami. Jak to přečtu? Nalepím na XML parser parsery různých ad-hoc syntaxí. Jak to zvaliduji? Nijak.

Mohu jít zpět ke kreslicímu prknu a navrhnout XML representaci vzorů, seznam udělat pěkně po prvcích, etc. Výsledek bude přesvědčivě XMLodiní, ale dlouhý a zpracovatelný pouze pro stroj (což ovšem nikdo nepřizná a bude stále tvrdit, že když je to XML, je to přece upravovatelné pro člověka).

A náš konfigurák přitom stále vůbec nejsou ty špičaté závorky, je to to, co dostaneme, když všechny ty špičaté závorky smažeme (nebo abstrahujeme pryč).

A to byl velmi jednoduchý příklad z konnfiguráku, který má hierarchickou strukturu, na kterou XML napasuješ snadno. Pokud bude konfigurace vypadat více jako deklarativní jazyk (sada pravidel s různými výrazy), tak zabalením do XML dosáhneš jediného, a to řádového prodloužení a znečitelnění celé věci. Na úrovni konfiguráku budeš mít přesně tutéž syntaxi, cos měl, jen to na serializační úrovni bude zabaleno do mraků špičatých závorek.

Okomentovaný konfigurák třeba zde

A teď to zkus srovnat s takovým konfigurákem Apache...

[default]

domain.xml GlassFishe.

Hele, co dělat všechny konfiguráky v Perlu! A ještě zazipovaný.

[Filip Jirsák]

Ale XML není syntaxe toho konfiguráku, to je až příslušné schéma

A co je lepší? Mít konfigurák s XML schématem, na jehož zpracování existuje spousta nástrojů, nebo konfigurák se schématem, které je zadrátované v kódu programu, který konfigurák načítá?

Výsledek bude přesvědčivě XMLodiní, ale dlouhý a zpracovatelný pouze pro stroj

Pro mne je naopak čitelný seznam v XML a nečitelný ten v ssh_config. V XML snadno přidám další položku, i když tam budu mít na počátku jen jednu, nebo jich budu chtít přidat dalších deset. V konfiguráku ssh_config v případě jedné položky na začátku musím začít zjišťovat, jak se víc položek vlastně zapisuje – zopakuju řádek SendEnv? Nebo uvedu víc hodnot na jeden řádek? A oddělují se mezerou, bílím místem, čárkou? A když budu potřebovat přidat víc položek a zalomit řádek, můžu zase znova zkoumat, jak se zalamují řádky…

A teď to zkus srovnat s takovým konfigurákem Apache...

Tam ty špičaté závorky máte také, takže tam máte všechny vaše „nevýhody“ XML, jenom to XML není, takže vám žádné existující nástroje pro XML nepomohou.

[Bilbo]

To je v XML občas "bordel" taky - setkal jsem se s programy, kde konfigurace je v XML a je citlivá na pořadí v jakém se napíšou tagy, které jsou parametry nadřazeného elementu (protože je k tomu debilně napsané DTD a to pořadí vyžaduje).

Takže zatímco třeba

<circle>
 <coord x="1" y="2" />
 <radius value="3" />
</circle>

je ok, tak

<circle>
 <radius value="3" />
 <coord x="1" y="2" />
</circle>

už je chyba.

I s XML se dají některé věci těžce "zprasit" takže uživatel pak místo "circle X=1 Y=2 R=3" může být nucen psát zhůvěřilosti typu:

<circle>
  <parameters>
    <radius>3</radius>
    <coordinates>
      <x>1</x>
      <y>2</y>
    </coordinates>
  </parameters>
</circle>

Případně se čas od času objeví i šílenosti typu

...
<config key="bla" encoding="base64" value="BORw0KGgoAAAA........" />
...

Pokud je autor programu "prase" tak XML to nezachrání, naopak to může i dost zhoršit.

[xkucf03]

To base64 se někdy používá pro vložení x509 klíče/certifikátu

Zadat klíč/certifikát jako odkaz na externí soubor umí každý (v XML to samozřejmě jde taky), ale v XML snadno můžu vložit ten soubor i dovnitř konfiguráku (pokud chci) a mít tak vše v jednom.

[Martin Mareš]

Nicméně jak sám píšete o pár příspěvků níže, takhle by se XML používat nemělo. Certifikát by neměl být vložen jako jakýsi amorfní shluk znaků, jehož strukturu parsuje někdo jiný, nýbrž by jeho struktura měla být popsána v XML.

[xkucf03]

když to kreativně olepím špičatými závorkami. Ale XML není syntaxe toho konfiguráku, to je až příslušné schéma, XML je zde pouze serializační formát

Svým způsobem máš pravdu – XML umožňuje jednoznačný zápis (serializaci) něčeho někam. Máme tu* elementy, atributy, textový obsah a samozřejmě další vnořené elementy (a tak dále až to libovolné úrovně složitosti). Samotné XML mi pomůže s tím, že nemusím váhat, jak zapsat více položek (prostě vložím víc elementů) nebo jak zapsat hodnotu s mezerami (nemusím řešit, zda bude v uvozovkách, apostrofech, zapsaná jen tak, escapovaná – prostě ji napíši dovnitř elementu nebo atributu). A není to zrovna málo – už jen kvůli tomuto pořádku a jednoznačnosti má smysl XML používat.

Samotné XML mi se syntaxí (nebo spíš sémantikou) konfiguráku nepomůže – to máš pravdu – ale s tím mi nepomůže ani textový konfigurák: v něm taky musím vědět, jak se která položka jmenuje (v XML by tomu odpovídal název elementu/atributu) a jaké může nabývat hodnoty – ale v textovém konfiguráku musím navíc řešit ty nízkoúrovňové věci (jak serializovat seznamy, mezery, escapovat atd.).

Se sémantikou konfiguráku mi pomůže XML schéma nebo DTD – na základě něj přesně vím, jak se ty elementy/atributy mají jmenovat, znám jejich textový popis, přípustný počet opakování (jestli tam mají být jen jednou, nebo jich můžu zapsat seznam…), přípustné hodnoty (číslo, datum, text, regulární výraz…). V textovém konfiguráku tohle samozřejmě jde taky, ale má to dvě nevýhody: jednak k tomu potřebuji obrovské množství komentářů, kde vyjmenuji všechny možné příklady (a to nejen z hlediska sémantiky, ale i syntaxe-serializace) a jednak to není deklarativní, komentáře nejsou strojově zpracovatelné, takže není možná automatická podpora ze strany softwaru (na základě komentářů mi např. editor nebude napovídat přípustné konfigurační volby).

<Host pattern="*.muni.cz">
   <SendEnv>LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES</SendEnv>
   ...
</Host>

Tohle je špatně navrženého XML konfiguráku – který vznikl jen obalením původního textového těmi <závorkami>, což je celkem na nic. Lépe by bylo:

<Host pattern="*.muni.cz">
   <SendEnv>LANG</SendEnv>
   <SendEnv>LC_CTYPE</SendEnv>
   <SendEnv>LC_NUMERIC</SendEnv>
   ...
</Host>

Dovnitř elementů by se neměla zanášet další syntaxe (v tomto případě oddělení položek mezerami) – zejména v takových případech, jako je výčet položek. V XML schématu budu mít uveden minimální a maximální počet výskytů <SendEnv/> a z toho snadno poznám, že jich můžu zadat víc (a taky nemusím zadávat žádný).

A teď to zkus srovnat s takovým konfigurákem Apache...

Konfiguráky Apache jsou jedny z nejhorších, které jsem kdy viděl. Velmi vzdáleně se tváří jako XML, ale z XML si berou jen ty ostré závorky a to ještě jen někdy. Člověk tam pak nachází takové obludnosti jako <Directory /> což připomíná element bez vnitřku, ale omyl: je to otevírací značka. Uvnitř je jakýsi text s jakousi vlastní specifickou syntaxí, kterou se člověk musí naučit. Dokonce ani není vnitřně jednotná – jednou se položky seznamu oddělují mezerami (Options Indexes FollowSymLinks MultiViews) a jindy zase čárkami (Order allow,deny). A podobných prásáren by se tam našlo víc. Raději nekomentovat

*) jmenné prostory, komentáře, CDATA atd. nechme teď stranou

[Martin Mareš]

XML umožňuje jednoznačný zápis (serializaci) něčeho někam

Ale kdež... jak uhodnu, jestli mám při té serializaci použít vnořený element nebo atribut? (Pokud tedy neusoudím, že používat atributy je vlastně vždycky špatně, protože taková schémata jsou nerozšiřitelná – nemohu se dodatečně rozhodnout, že hodnota může být strukturovaná.)

Nemohu se ubránit dojmu, že pro serializaci stromových struktur (a nic obecnějšího v XML nenareprezentujete) existují mnohem jednodušší a praktičtější prostředky. Za všechny zmiňme třeba S-expressions.

[Filip Jirsák]

Jak se popisuje schéma S-expressions? Jak se tam vkládají komentáře? Kolik existuje nástrojů a knihoven pro práci s nimi?

[Martin Mareš]

Jak se popisuje schéma S-expressions?

Je něco takového doopravdy potřeba? Dává smysl zavádět schémata, kterými se dá vyjádřit pouze minimální podmnožina syntaktických omezení? Mnohdy by se daleko víc hodilo, aby to nebylo nějaké formální schéma, nýbrž program, který syntaxi zkontroluje kompletně.

Jak se tam vkládají komentáře?

Od středníku do konce řádku.

Kolik existuje nástrojů a knihoven pro práci s nimi?

V každém LISPu aspoň jedna

Tohle nemá smysl porovnávat. Když vám v nějakém jazyce chybí knihovny pro práci s XML, tak je to příležitost k bezmocnému úpění. Pokud chybí parser S-expressions, tak si těch 100 řádků kódu prostě napíšete. On je to opravdu formát, který má jednoduchost i jinde než v reklamních letácích

[Filip Jirsák]

Schémata se nepoužívají jenom ke kontrole, ale také třeba k dokumentaci nebo nápovědě. To já osobně považuju za velkou výhodu – zmáčknu klávesovou zkratku, a dostanu na výběr, jestli chci vložit Indexes, MultiViews nebo FollowSymLinks, a nemusí hledat, jestli se to píše Indexes nebo index, MultiViews nebo Multiviews… Pokud tam má být kladné číslo, rovnou to vidím atd.

Jedinou nevýhodu oproti S-expressions vidím v tom, že se v XML nedají psát zkrácené koncové tagy </>. Druhá je pak ještě v parsování entit, ale to můžu vždy obejít tak, že řeknu, že v mém konfiguráku nejsou entity kromě systémových povolené…

Navíc XML je také modulární – plugin může být jednoduše nakonfigurován uvnitř hlavního konfiguračního souboru, jenom použije vlastní jmenný prostor.

[Martin Mareš]

Schémata se nepoužívají jenom ke kontrole, ale také třeba k dokumentaci nebo nápovědě.

Vůbec mi nepřijde zřejmé, že je správně pokoušet se o strojově čitelnou dokumentaci za cenu toho, že bude neúplná. Neplnil by účel daleko lépe nějaký prostý formát dokumentace navázaný na strukturu stromu? To jde vcelku snadno navrhnout nezávisle na tom, jak stromy reprezentujete.

Jedinou nevýhodu oproti S-expressions vidím v tom, že

Já vidím zásadní nevýhodu zejména v tom, že je to celé úplně zbytečně překomplikované. XML neumí víc než ty S-expressions, a přitom má o několik řádů složitější specifikaci.

[Filip Jirsák]

Píšete o případu, kdy se člověk zabývá jedním nebo několika málo konfiguráky a jejich syntaxi i způsoby konfigurace zná nazpaměť. Já mluvím o případu, kdy člověk potřebuje jednou za půl roku změnit jednu hodnotu v konfiguraci SSH, pak nasazuje nové webové stránky, tak potřebuje změnit tři hodnoty v konfiguráku webového serveru – a mezi tím dělá něco úplně jiného, programuje, vytváří web nebo třeba zahradničí. V tom druhém případě je neocenitelná služba, pokud v editoru zmáčknu klávesovou zkratku a dostanu nabídku přípustných tagů a možných hodnot. Nemusím nic hledat v dokumentaci, protože v 95 % případů si už ze samotné nabídky vyberu, co potřebuju. Sice je pravda, že ani pomocí schémat nejde vyjádřit všechna omezení na konfiguraci, ale jde toho vyjádřit mnohem víc, než co běžně podporují textové editory pro ad-hoc formáty konfiguračních souborů.

Jediné, co je na specifikaci XML složité, jsou entity. Čemuž se lze snadno vyhnout a prostě do specifikace konfiguračního souboru napsat, že je to XML, které odpovídá určitému schématu, odpovídá dalším kontextovým pravidlům, která nelze vyjádřit v schématu, a nepoužívá jiné než systémové entity. Parser pak nebude o moc složitější, než parser S-expressions (pokud tedy nepoužijete nějaký už hotový).

[Martin Mareš]

Já mluvím o případu, kdy člověk potřebuje jednou za půl roku změnit jednu hodnotu v konfiguraci SSH [...]

U slušně napsaných konfiguráků úplně stačí podívat se na komentář, který u dotyčné položky autor zanechal.

Jediné, co je na specifikaci XML složité, jsou entity.

Eh... namátkově: processing instructions, volba znakové sady, CDATA, atributy.

[Filip Jirsák]

U slušně napsaných konfiguráků úplně stačí podívat se na komentář, který u dotyčné položky autor zanechal.

To by u toho bloku directory v konfiguráku Apache byl ten komentář hodně dlouhý. Navíc mi většinou úplně stačí seznam názvů položek, který přečtu výrazně rychleji, než celý komentář.

Eh... namátkově: processing instructions, volba znakové sady, CDATA, atributy.

PI začíná <? a končí prvním ?>, CDATA začínají <![CDATA[ a končí prvním ]]>, hodnota atributu začíná dvojitou uvozovkou a končí první další uvozovkou. Co je na tom složitého? Volbu znakové sady musíte řešit u každého formátu do té doby, než se budou standardně i na souborových systémech ukládat do rozšířených atributů. A u toho konfiguráku klidně můžete říct, že musí být v UTF-8 (pokud na to teda budete psát ten vlastní parser).

[Martin Mareš]

Navíc mi většinou úplně stačí seznam názvů položek,

Právě u toho Directory je seznam položek, které mohou být uvnitř, proklatě dlouhý (skoro všechny existující direktivy).

Co je na tom složitého?

Především to, že věcí (byť jednoduchých), o které se korektní parser XML musí postarat, jsou mrtě. Vybrat si nějakou podmnožinu a napsat parser pouze na ni, je cesta do pekel, protože Vám rázem přestane fungovat polovina nástrojů, neboť budou generovat věci, které Váš parser neumí.

Ale pokud chcete, klidně můžeme uspořádat souboj Vy napíšete korektní XML parser, já korektní parser S-expů a schválně, který bude jednodušší.

(Jinak volbu znakové sady je u formátu dat v dnešní době sotva potřeba řešit. UTF-8 je dostatečně obecné.)

[Filip Jirsák]

Především to, že věcí (byť jednoduchých), o které se korektní parser XML musí postarat, jsou mrtě. Vybrat si nějakou podmnožinu a napsat parser pouze na ni, je cesta do pekel, protože Vám rázem přestane fungovat polovina nástrojů, neboť budou generovat věci, které Váš parser neumí.

Neznám žádný nástroj, který by svévolně generoval do výstupního souboru entity. Naopak bych myslím měl dost problémů k vygenerování nesystémových entit spoustu nástrojů donutit.

Ale pokud chcete, klidně můžeme uspořádat souboj Vy napíšete korektní XML parser, já korektní parser S-expů a schválně, který bude jednodušší.

Parser XML (bez entit) bude trochu delší, protože je v XML víc kontextů. Ale složitost bude myslím stejná. Otázka taky je, proč psát nový parser, když si mohou vybrat ze spousty existujících. On se ten souboj totiž taky dá uspořádat opačně – sestavit celou infrastrukturu (parser, validátor, editor, transformační nástroj, dotazovací nástroj) třeba v pěti jazycích. Pro XML to bude znamenat vybrat si vhodné knihovny, pro S-expressions budete muset většinu toho napsat.

Pro jednoúčelovou utilitu, která bude samotná desetkrát menší, než XML parser, je XML samozřejmě kanón na vrabce – ale to bude jakákoli konfigurace uložená jako stromová struktura, takové nástroje si zpravidla vystačí s mapou klíč=hodnota (škoda, že pro serializaci takového formátu také neexistuje nějaký jeden široce používaný formát). Ale když je potřeba něco složitějšího, vyplatí se podle mne rovnou použít XML, protože tak zadarmo získáte spoustu funkcionality, kterou můžete hned využít – schémata, validaci a dokumentaci, jmenné prostory, vkládání externích souborů (Xinclude, ne entity), spoustu nástrojů…

[Martin Mareš]

Neznám žádný nástroj, který by svévolně generoval do výstupního souboru entity.

A co třeba CDATA?

On se ten souboj totiž taky dá uspořádat opačně – sestavit celou infrastrukturu (parser, validátor, editor, transformační nástroj, dotazovací nástroj) třeba v pěti jazycích.

Problém ovšem je v tom, že o tuto infrastrukturu spousta lidí nestojí, alespoň v podobě, kterou nabízí XML. Jak už bylo v této diskusi zmíněno, validita XML neslibuje vůbec nic stran syntaktické korektnosti (říká pouze to, že korektnost nebyla porušena jistým zjevným způsobem). Transformační a dotazovací nástroje nad XML jsou neuvěřitelně těžkopádné a jsou snůškou ad-hoc technik, nikoliv něčím, co by mělo jasně definovanou výpočetní sílu.

Mohl by to být věru zajímavý souboj, kdybyste chtěl, aby ta infrastruktura opravdu fungovala

Celkově mi přijde, že ekosystém okolo XML by měl posloužit zejména k tomu, aby se lidé poučili z jeho chyb a nahradili ho něčím solidním, co nebude zbytečně komplikované.

[Filip Jirsák]

A co třeba CDATA?

Ani takový. Navíc parsování CDATA je triviální záležitost, těžko může být něco jednoduššího.

Jak už bylo v této diskusi zmíněno, validita XML neslibuje vůbec nic stran syntaktické korektnosti (říká pouze to, že korektnost nebyla porušena jistým zjevným způsobem).

Nejsem si jist, zda se bavíme o stejné validitě. Já mluvím o tom, že dokument odpovídá nějakému schématu. Tím můžete kontrolovat i povinnost či nepovinnost elementů, pořadí, přípustné hodnoty… RelaxNG myslím umí kontrolovat i kontextové závislosti.

Transformační a dotazovací nástroje nad XML jsou neuvěřitelně těžkopádné a jsou snůškou ad-hoc technik, nikoliv něčím, co by mělo jasně definovanou výpočetní sílu.

Jenže jsou a fungují. Navíc na transformaci konfiguráku nepotřebuju nástroj, který místo 0,1 sekundy poběží jen 0,03 sekundy.

Celkově mi přijde, že ekosystém okolo XML by měl posloužit zejména k tomu, aby se lidé poučili z jeho chyb a nahradili ho něčím solidním, co nebude zbytečně komplikované.

Klidně. Ale kdo to vymyslí, jak dlouho bude trvat, než se to prosadí? A bude to skutečně tak odlišné od XML?

[Martin Mareš]

Navíc parsování CDATA je triviální záležitost, těžko může být něco jednoduššího.

Jak už jsem psal, všechno to jsou triviality, jen jich je moc. Svým způsobem celé XML je jedna trivialita, kterou bohužel někdo nakrmil kyblíkem steroidů

Nejsem si jist, zda se bavíme o stejné validitě. Já mluvím o tom, že dokument odpovídá nějakému schématu.

Já mluvím o tom, že dokument je korektní, čili že splňuje nějakou množinu omezení. To zahrnuje jak podmínky, které se dají vyjádřit v XML schématech, tak i podmínky složitější (ale stále často potřebné), jako třeba že hodnota nějakého elementu je prvočíslo, syntakticky správné URL nebo třeba syntakticky správný Céčkový program.

jak dlouho bude trvat, než se to prosadí?

Na tom moc nezáleží. Na dobrých myšlenkách je důležitá jejich existence, masovost málokdy. Linux také nepoužívám proto, že by se nějakým způsobem prosadil.

A bude to skutečně tak odlišné od XML?

Na jisté úrovni nebude. Zase to budou jenom stromy (z tohoto pohledu XML neumí nic, co by lidstvo neznalo už před 50 lety). Ale třeba se s nimi bude pracovat o něco příjemněji.

[Filip Jirsák]

Teď už zbývá jenom aby nějaká ta dobrá myšlenka existovala.

Na jisté úrovni nebude. Zase to budou jenom stromy (z tohoto pohledu XML neumí nic, co by lidstvo neznalo už před 50 lety). Ale třeba se s nimi bude pracovat o něco příjemněji.

V čem by se tedy ten formát lišil? Že by se místo špičatých závorek použily složené? To mi jako zásadní změna nepřipadá…

[Martin Mareš]

V čem by se tedy ten formát lišil?

Zejména v tom, že by zmizela spousta balastu: rozlišení vnořené elementy vs. atributy, opakování jmen elementů, entity, znakové sady, CDATA a tak dále. Zbylo by jen přímočaré kódování stromů pomocí závorek.

[Filip Jirsák]

Rozlišení vnořených elementů vs. atributů by zhoršilo čitelnost; opakování jmen elementů také, ale ponechal bych uvádění jména koncového elementu jako volitelné. Znakové sady jsou nutnost, dokud se plně nepřejde na UCS-4, UTF-8 není formát vhodný pro všechny jazyky. Jenom by znaková sada neměla být uvnitř dokumentu, ale v metadatech, ale to je taky na dlouho. CDATA mi připadá jako mnohem lepší způsob vkládání binárních dat, než obvykle používané base64 kódování. Pravda je, že je opět navržen hlavně s ohledem na ruční zpracování, možná by se hodilo mít ještě jeden formát pro binární data, který by umožnil jejich ukládání po shlucích s délkou určenou na začátku. To by umožnilo efektivnější strojové zpracování, ale zase by to formát komplikovalo a nebylo by to čitelné pro lidi.

[Martin Mareš]

Rozlišení vnořených elementů vs. atributů by zhoršilo čitelnost

Konstrukce (element (xyz 1) (abc 2)) mi tedy nepřijde o nic méně čitelná než <element xyz="1" abc="2">.

ponechal bych uvádění jména koncového elementu jako volitelné

Další komplikace.

UTF-8 není formát vhodný pro všechny jazyky

Proč vlastně?

CDATA mi připadá jako mnohem lepší způsob vkládání binárních dat

Způsob vkládání binárních dat, kterým nejdou vložit binární data, která obsahují určité podřetězce, je dost nanic.

[Filip Jirsák]

Konstrukce (element (xyz 1) (abc 2)) mi tedy nepřijde o nic méně čitelná než <element xyz="1" abc="2">.

Pokud se na XML díváte jenom jako na formát pro uložení obecného stromu, pak možná ne. Když se na něj podíváte zároveň jako na značkovací jazyk, pak už je v tom výrazný rozdíl.

Proč vlastně?

Některé asijské jazyky mají v UTF-8 průměrně 3 bajty na písmeno, v jiném kódování (UCS-2?) jsou to 2 bajty na písmeno.

Způsob vkládání binárních dat, kterým nejdou vložit binární data, která obsahují určité podřetězce, je dost nanic.

Pro počítač je samozřejmě lepší uložit jako prefix délku dat a pak samotná data bez escapování, pro člověka je to ale nečitelné, ten dá naopak přednost rozumnému escapování. CDATA volí druhou variantu, takže tam nějaké escapování být musí – a escapovat jediný triplet ]]> (při serializaci to musíte nahradit za ]]>]]&gt;<![CDATA[) je podle mne rozumná volba

[Martin Mareš]

Když se na něj podíváte zároveň jako na značkovací jazyk, pak už je v tom výrazný rozdíl.

Možná je na čase opustit představu, že jeden jazyk může být vhodný současně pro značkování textu a pro ukládání obecných stromových dat. Pro značkování textu psaného člověkem je mnohem příjemnější než XML obecné SGML (konstrukce typu &left;b/tučně/ se píší velmi snadno). Byť samozřejmě může existovat přímočará projekce syntaktického stromu SGML do nějakého jazyka pro popis stromů.

Některé asijské jazyky mají v UTF-8 průměrně 3 bajty na písmeno, v jiném kódování (UCS-2?) jsou to 2 bajty na písmeno.

Záleží na tom doopravdy? Stojí za to zkrátit texty v některých jazycích o 50% (ze 3 bajtů na 2) za cenu toho, že v jiných jazycích je prodloužíte o 100% (z 1 bajtu na 2)? Navíc UCS-2 evidentně nestačí, takže je potřeba uchýlit se buďto k UTF-16 (což je obludnost, která kombinuje prostorovou nenažranost UCS-2 s proměnlivou délkou UTF-8) nebo rovnou k UCS-4, čímž ovšem prodloužíte texty v prakticky všěch jazycích světa.

Navíc si troufám tvrdit, že většina textů na světě je a bude v čistém ASCII (mimo jiné proto, že dost pravděpodobně je většina existujících textů textovým zápis nějakých automaticky generovaných dat), takže prodloužení ASCII na dvojnásobek je mnohem větší zlo než 3-bajtové čínské znaky.

Z toho mi vychází, že UTF-8 je velmi rozumný kompromis. (A komu na velikosti textů opravdu záleží, ten stejně nejspíš použije nějakou dodatečnou kompresi, jež nevýhody UTF-8 odstíní.)

pro člověka je to ale nečitelné, ten dá naopak přednost rozumnému escapování.

Pro člověka jsou binární data nečitelná tak jako tak, takže na čitelnosti escapování sotva záleží. (Nemluvě o tom, že téměř každý textový editor binární data nevratně zmrší, což činí ruční editování souborů s binárními částmi tak jako tak značně problematickým.)

[Filip Jirsák]

Ta „binární data“ klidně může být nějaký textový soubor. A i kdyby to bylo něco skutečně binárního, často člověk potřebuje jen najít konec těch dat. Každopádně existující XML parsery různá kódování umí, umí parsovat i CDATA, a zároveň nevyžadují jejich přítomnost v dokumentu, takže když si napíšete konfigurák bez CDATA a v UTF-8, parser nebude mít nic proti.

[Martin Mareš]

člověk potřebuje jen najít konec těch dat

Což se očima v hromadě rozsypaného čaje hledá opravdu dobře

Jinými slovy člověku to nepomuže, stroji práci zkomplikuje.

[Filip Jirsák]

Vyhledávat text snad umí i Poznámkový blok.

[Martin Mareš]

Záleží na tom, na co chcete CDATA používat. Pokud jenom na escapování znaků, pak je daleko šikovnější mechanismus, který umožní na začátku bloku definovat, čím bude blok končit (jako << v shellu nebo boundary v MIME). Pokud na nějaká "binárnější" data, pak se především můžete rozloučit s tím, že Vám je běžný textový editor nerozsype, ať už jsou ukončena ]]> nebo třeba "amen".

Chápu, za jakým účelem CDATA vznikla, jen jsem přesvědčen, že téhož účelu jde dosáhnout daleko vhodnějšími prostředky než obskurní syntaxí s hranatými závorkami.

[xkucf03]

UTF-8 je opravdu asi nejlepším kódováním, ale je dobré mít možnost volby. XML je na to připravené a pokud v něm člověk nedeklaruje jiné kódování, použije se právě UTF-8. Ale dokud se nebude kódování souboru běžně ukládat do metadat v souborovém systému* nebo se celý svět nedohodne na jednom kódování, je potřeba situaci nějak řešit – a XML ji řeší právě tím, že umožňuje uvést kódování na začátku souboru – nic moc lepšího se vymyslet nedá.

*) např. při přenosu po HTTP se obvykle kódování posílá v hlavičkách, takže tam není problém, ale u souborů na disku se ta informace ztrácí.

[Martin Mareš]

uvést kódování na začátku souboru

To ovšem funguje jenom tehdy, když použijete kódování, které je nadmnožinou ASCII. Třeba s UCS-2 funguje XML jen proto, že je na něj speciální hack ve specifikaci. To nezní rozumně. Nevidím jinou konsistentní možnost, než buďto kódování uvádět vně souboru, nebo umožnit uvnitř souboru kódování přepnout (takže začátek bude třeba v ASCII a bude tam řečeno, jak číst zbytek souboru). XML nedělá ani jedno z toho, takže je v praxi použitelná pouze část kódování, která jsou buď nadmnožiny ASCII nebo zadrátovaná ve specifikaci. Tomu tedy říkám rozšiřitelnost

[xkucf03]

rozlišení vnořené elementy vs. atributy

Tohle by možná šlo. Ale na druhou stranu si nemyslím, že by existence atributů v XML nějak překážela – spíš se může hodit.

opakování jmen elementů

Možné to je, ale co z toho? Počítač by si ty koncové značky/závorky našel. Člověku by někdy mohly chybět… ale to je celkem jedno. Nějaký zásadní přínos? Pár ušetřených bajtů? Nevím.

entity

Entity někdy slouží k prostému zakódování znaků (např. češtiny do kódování, které ji nepodporuje). Takové by šly oželet. Jenže entity se dají používat i jako „makro“ pro dosazování textu – a těch by, podle mého, byla škoda. Další použití entit je pro zápis speciálních znaků (např. uzavíracích závorek) – tyhle entity by musely zůstat nebo by se musel vymyslet jiný způsob escapování těchto znaků – což by zjednodušení nepřineslo – když už budeme mít escapování, můžeme rovnou nechat entity.

CDATA

A co když budu chtít zapsat delší text, který obsahuje speciální znaky? Budu muset všechny escapovat. Proto mi přijde vhodnější udělat složitější parser (který se píše jen jednou nebo několikrát) než dělat složitější práci všem uživatelům a otravovat je escapováním (uživatelé totiž nepíší jeden dokument, ale miliony nebo miliardy dokumentů – tudíž práce „ušetřená“ při vývoji parseru by se lidem vrátila jako bumerang v podobě pracnějšího zápisu dokumentů – což je ve výsledku dost nevýhodné).

znakové sady

Kódování? Ale jak to řešit? Donutit všechny lidi, aby používali UTF-8? To mi přijde jako krok zpět – v devadesátých letech se nás MS taky snažil donutit používat cp1250, ale selhalo to, byly z toho akorát problémy a lidi ztratily spousty hodin a nervů řešením „rozbité češtiny“. A teď je běžnou praxí, že se kódování uvádí, např. v HTML stránce nebo v e-mailu a už to funguje. Je potřeba se smířit s tím, že kódování je na světě víc a že se nepodaří lidem naordinovat jediné správné.

Případně by kódování mohlo ležet „mimo formát“, ale to jde třeba u HTTP nebo u MIME, ale u souborů na disku to moc nefunguje. Dokud se tohle nevyřeší, je potřeba mít možnost deklarovat kódování uvnitř souboru. XML na to jde chytře a u UTF-8 se kódování deklarovat nemusí.

Zbylo by jen přímočaré kódování stromů pomocí závorek.

A pak už jen zbývá dopsat všechny ty technologie, které nad XML existují. Aneb, kde byli ti zastánci „jednoduchých formátů“ když se XML rozjíždělo? Proč si nevytvořili ty „nadstavbové“ technologie, jako má XML, nad těmi svými formáty stejně rychle jako to stihlo XML? Nebo rychleji? Vždyť by to mělo být méně práce, když se nemusí řešit takové blbosti jako kódování, CDATA atd.

[Martin Mareš]

Člověku by někdy mohly chybět…

Já si naopak myslím, že člověku velice překáží. Lidské chápání je často omezeno tím, kolik dat najednou lze vnímat. Pokud ta data naředíte balastem, půjdou psát i chápat efektivněji.

Jenže entity se dají používat i jako „makro“ pro dosazování textu

Tohle nepatří do formátu dat. Pokud chcete používat makra, pořiďte si preprocesor. Tak silný, jak potřebujete. (Mně například přijde poněkud zvrhlá idea používat v dnešní době preprocesor, který není turingovsky úplný, takže dříve či později narazím na nějaké jeho omezení.)

A co když budu chtít zapsat delší text, který obsahuje speciální znaky?

Co když budu chtít udělat tak triviální věc, jako vložit do jednoho dokumentu textovou podobu jiného? CDATA uvnitř jiných CDAT snadno neudělám…

Taktéž pokud si zvolíte střídmější sadu znaků se speciálním významem než má XML (třeba v S-expech to jsou uvnitř řetězců pouze uvozovky), značně tím tento problém minimalizujete.

Ale jak to řešit? Donutit všechny lidi, aby používali UTF-8?

Dokud se neobjeví něco ještě obecnějšího než UTF-8, mohou všichni spokojeně používat UTF-8. Až se jednou objeví, můžete kódování ukládat externě, nebo se ještě lépe na Unixových systémech spolehnout na locale (pokud Vaše locale bude určovat charset obecnější než UTF-8, není problém, aby programy při ukládání dat na disk do tohoto charsetu překódovávaly a pak je v tomto charsetu načítaly; v zásadě podobně to teď na Unixech s textovými soubory chodí a funguje to rozumně).

XML na to jde chytře a u UTF-8 se kódování deklarovat nemusí.

Jak už jsem psal o pár příspěvků vedle, nijak chytře na to nejde a mimo nadmnožin ASCII a pár hacků ve specifikaci jeho volba znakové sady nefunguje.

Aneb, kde byli ti zastánci „jednoduchých formátů“ když se XML rozjíždělo? Proč si nevytvořili ty „nadstavbové“ technologie, jako má XML, nad těmi svými formáty stejně rychle jako to stihlo XML?

Myslím, že důvody jsou dva. Jednak u mnoha z těchto "technologií" nebyli přesvědčeni o tom, že jsou k něčemu dobré (já si to například o schématech nemyslím dodnes, přijde mi, že správná cesta vede jinudy). A také proto, že vymyslet něco jednoduchého a elegantního není vůbec jednoduché.

Docela zajímavou paralelu můžete sledovat na poli systémů pro správu verzí. Po mnoha letech vývoje stále složitějších a složitějších systémů přišel najednou Git, jehož základy jsou téměř triviální, ale trvalo dlouho, než byl někdo schopen udělat ten správný myšlenkový skok a uvědomit si, co je doopravdy důležité.

Na XML se projevuje starý dobrý Second-system effect – autoři XML si dobře uvědomovali, jakými problémy trpěly starší formáty, a usmysleli si, že každou z těchto věcí vymyslí lépe a sofistikovaněji. Jen je někdy rozumnější nezalepovat jeden problém po druhém a místo toho se zaměřit na základy. To se bohužel nestalo.

[Martin Mareš]

když už budeme mít escapování, můžeme rovnou nechat entity.

Ještě dodávám, že mezi psaním backslashe před speciální znak, aby ztratil svůj speciální význam, a syntaxí entit vnímám dost podstatný skok ve složitosti (jak na straně parseru, tak na straně člověka editujícího text – při psaní příspěvků do této diskuse jsem už několikrát mrmlal nad tím, kolik práce dá napsat ukázku nějakého tagu, když by přitom stačil jediný backslash).

[Filip Jirsák]

Entity někdy slouží k prostému zakódování znaků (např. češtiny do kódování, které ji nepodporuje). Takové by šly oželet. Jenže entity se dají používat i jako „makro“ pro dosazování textu – a těch by, podle mého, byla škoda. Další použití entit je pro zápis speciálních znaků (např. uzavíracích závorek) – tyhle entity by musely zůstat nebo by se musel vymyslet jiný způsob escapování těchto znaků – což by zjednodušení nepřineslo – když už budeme mít escapování, můžeme rovnou nechat entity.

Já to mám teda přesně opačně. Ponechal bych systémové entity (&, <, >, " a '), ponechal bych znakové entity, a zrušil bych „makra“, která nikdo nepoužívá a málokdo jim rozumí. Pro vkládání jiných částí se dá použít XInclude.

[xkucf03]

Zase to budou jenom stromy

Ono to nemusí být stromy – můžeme si třeba posílat vyexportované relační databáze – mnohdy by to byl vhodnější popis reality než jakýkoli strom Ostatně některé programy to tak dělají, když si konfiguraci ukládají např. do sqlite databázových souborů.

[Martin Mareš]

A není relace jenom speciální případ stromu, u kterého jste celou strukturu splácnul do dvou hladin?

[xkucf03]

Je Rozdíl je spíš v logickém pohledu na věc, zapsat relace do XML samozřejmě jde. BTW: neexistuje na to nějaký standardizovaný formát? Zatím jsem viděl leda formáty pro „dump databáze do XML“ specifické pro daný SŘBD.

[default]

Parser XML (bez entit) bude trochu delší, protože je v XML víc kontextů. Ale složitost bude myslím stejná.

Jednoduchý parser XML jde napsat jedním regulárním výrazem v Perlu.

[Martin Mareš]

Pokud "jednoduchý" znamená "ignoruje naprostou většinu normy", pak souhlasím. Jinak sem s ním.

[xkucf03]

Na atributy se dá rezignovat a vůbec je nepoužívat. Je fakt, že jsou trochu nesystémové, v podstatě místo nich stačí vnořený element, který by měl minimální počet výskytů 0 nebo 1 a maximální právě 1. Jenže z toho by se někteří lidé by se vztekali, že nestačí napsat id="xyz", ale musí psát <id>xyz</id>*. Tak kvůli nim asi ty atributy existují

*) což je o celé tři znaky delší zápis – jak skandální!

[Martin Mareš]

což je o celé tři znaky delší zápis – jak skandální!

No skandální na tom je především to, že naprosto zbytečně opakujete totéž jméno dvakrát. Takže pokud si atribut pojmenujete "id", jsou to jen 3 znaky navíc, pokud ovšem "satanarcheolegenialkohrozny", je to jaksi víc.

</id> má funkci uzavírací závorky, takže je nanejvýš divné ho tak nepsat.

[default]

</id> má funkci uzavírací závorky, takže je nanejvýš divné ho tak nepsat.

Ani ne.

[xkucf03]

V tomhle máš pravdu – zjistit, která uzavírací závorka patří ke které je pro stroj snadné. Zajímavé ale je, že kritici XML často argumentují tím, že XML je vhodné pro strojové zpracování a nevhodné pro člověka – přitom tady je to přesně naopak: ono redundantní opakování názvu v uzavírací „závorce“ (<id/>) je vhodné pro člověka*, který na první pohled vidí, který element je uzavírán a nemusí počítat závorky – navíc to slouží jako kontrola proti překlepům a dalším hloupým chybám – protože taková hloupá chyba s velkou pravděpodobností způsobí invaliditu dokumentu, a je tak hned odhalena.

*) programu je to jedno, ten by si závorky dopočítal

[Martin Mareš]

redundantní opakování názvu v uzavírací „závorce“ <id/>) je vhodné pro člověka

Opravdu? Pokud mám do sebe vnořených několik elementů stejného jména, pranic nepoznám. Zato každý rozumný textový editor umí ukazovat párování závorek a také odsazovat.

[xkucf03]

Rozumný textový editor* mi ukáže párovou značku tak, jako mi ukáže párovou závorku. Rozdíl spíš bude, když si vypíši soubor třeba pomocí příkazu cat nebo less – tam mi spíš pomůže ukecanější XML. Navíc, aby mi editor zvýraznil párovou závorku, tak na ni většinou musím najet kurzorem – kdežto párové značky vidím všechny najednou.

*) např. jEdit, vim, emacs, Netbeans

[Martin Mareš]

Rozdíl spíš bude, když si vypíši soubor třeba pomocí příkazu cat nebo less

Tam pomůže jednoduchý filtr, který obsah souboru správně poodsazuje, aby byla vidět jeho struktura. Opět je ho daleko jednodušší napsat pro S-expy než pro XML.

Navíc, aby mi editor zvýraznil párovou závorku, tak na ni většinou musím najet kurzorem – kdežto párové značky vidím všechny najednou.

Opět jenom za předpokladu, že nevnořujete více elementů téhož jména do sebe. Některé editory navíc umí závorky barvit podle hloubky vnoření, takže vidíte párování, aniž byste rejdil kurzorem.

Jinak tohle všechno potřebujete jen tehdy, když neodsazujete.

Zkrátka přehlednost párování závorek by měla být záležitostí nástrojů, ne formátu.

[xkucf03]

Tam pomůže jednoduchý filtr, který obsah souboru správně poodsazuje, aby byla vidět jeho struktura.

Ukázka příšerně* formátovaného XML:

curl http://nekurak.net/

Uděláme ho čitelné pro člověka – odsadíme:

curl http://nekurak.net/ | xmlindent

Stačí jeden příkaz, roura

*) taky kdo by se s tím patlal, když je na druhé straně prohlížeč, který to zchroustá i takhle – a uživatele formátování XHTML nemusí zajímat.

[Filip Jirsák]

Několik do sebe vnořených elementů stejného jména ve většině případů znamená špatně navržené schéma.

[Martin Mareš]

Proč? Spousta dat je naprosto přirozeně rekurzivní. Představte si, že chcete popisovat nějaké výrazy, například podmínky.

[Filip Jirsák]

Myslím, že v případě konfiguračních souborů je to opravdu výjimečné. Pokud budu chtít popisovat obecné podmínky, hodně bych se rozmýšlel, zda jde pořád ještě o deklarativní zápis, nebo jestli to už náhodou nejsou instrukce, program – a pokud ano, pak se XML zdaleka vyhnu a použiju nějaký programovací jazyk.

[Martin Mareš]

OK, jiný příklad: blok Directory v konfiguraci Apache. Je naprosto přirozené, aby se dal vnořovat.

[Filip Jirsák]

Ano, to je těch 5 %.

[Jardík]

Napsal jsem to v podstatě výše, není nutné to sem psát 100x

[Bum]

To tazko. Prve co som zmenil bolo toto. Nie ze by som to pouzival, ale usetril som si nadavky od manzelky. Ja pouzivam alt+f4 . alt+tab . alt+f9 a alt +f2. a celkom mi to staci. na lavej stane mi to nejak vadilo aj napriek tomu. :)

[ferkox64]

Pouzivam Ubuntu cez dva roky ale co pozeram ide dolu vodou. Ked sa tak na to pozeram, nechapem co je na ubuntu take uzasne(okrem marketingu). Ze vhodne pre zaciatocnikov? V poslednej verzii tam nie su ziadne poriadne klikatka(sluzby a opravnenia dali prec), a ostatne treba nainstalovat. Namatkovo som si skusil OpenSuse a musim povedat, ze je ovela lepsie pre zaciatocnika(potencionalne i Mandriva). Nechapem preco nemozu urobit nejake jednoduche ubuntu ovladacie centrum, aby sa tam lahko naklikali veci ktore sa nedaju spravit so stavanymi GNOME klikatkami. Nie-pouzi GConf a Terminal(ja ich rad pouzivam, ale na jednej strane pisu ze pre ludi a na druhej tam vsetko osekavaju a kazdu pokrocilejsiu vec musi clovek riesit v terminali-schyzofremia) A takuto zmenu spravit v "LTS", len cas ukaze ake to bude mat dosledky pre uzivatelov.

[jan]

Pouzitelnost pro "zacatecniky" ber napred s pohledu balicku, tebou udavana Mandriva a (Open)Suse pouziva RPM (jeste bych pro "zacatecniky" zaradil Fedoru), Ubuntu ma balickovaci system Debianu (neb je na Debianu postaven). Tudiz Ubuntu je GNU/Linuxova distribuce pro "zacatecniky" postavena na Debianu.

[PetrHL]

http://ubuntu-tweak.com/

[OndraZX]

"Nepratele" Ubuntu se deli do dvou skupin:

- prvni skupina tvrdi, ze Ubuntu je klikaci distribuce urcena akorat pro lamy.

- druha skupina si stezuje, ze Ubuntu nema klikaci konfiguracni nastroje typu Yast, Mandrake Control Center

Uzivatele Ubuntu to neresi, protoze svou distribuci nepotrebuji nastavovat, oni ji vyuzivaji pro svou praci. Ubuntu je proste po instalaci nastaveno tak, ze 90% uzivatelu nema co nastavit. Pokud ano, existuji nastroje aby se mohli v konfiguraci "vrtat" - tyto nastroje je vsak nutne doinstalovat. Ja napriklad po instalaci Ubuntu doinstaluji balik restricted-extras, zmenim sporic obrazovky a ve Firefoxu zmenim vychozi stranku a schovam panel s odkazy. Tot vse co potrebuji pro svou praci. Mel jsem take obdobi, kdy jsem se v Linuxu "vrtal" a verim ze by mne Ubuntu moc svymi vlastnostmi neuspokojilo a pouzival bych jinou distribuci, ale v soucasne dobe od Linuxove distribuce ocekavam funkcnost - nic vic - na hrani uz bohuzel nemam cas. Pokud narazim na nejaky problem vim, ze na Wiki, nebo foru Ubuntu najdu reseni - porovnejte si obsah napr. se zminovanym OpenSuse wiki, forem - i kdyby prodavali OpenSuse v pozlacenych krabicich - tak to je ten rozdil, kterym se Ubuntu od ostatnich distibuci lisi - dostatkem informaci.

PS: je to cca tyden co jsem zkusil OpenSuse LXDE verzi - opet splacanina - kdy uz konecne pochopi, ze 1 oblast pouziti = 1 instalovana aplikace. A ne uzivatele zahrnout mnozstvim polofunkcnich aplikaci.

[Václav Kramář]

Ano, *buntu je opravdu pro uživatele, kteří nainstalují a fungují. Ale tito uživatelé bývají nezřídka konzervativní a tenhle kotrmelec s layoutem jim může být hodně proti srsti. Na druhou stranu třeba taková Mandriva One taky funguje docela dobře (a určitě i jiné distribuce, které jsem nevyzkoušel). Jenom zkrátka vychází příliš často a jednotlivé verze mají příliš krátkou podporu. Ubuntu 8.04 bych bez váhání strčil do ruky jako jednodušší a spolehlivější řešení komukoli, kdo si dokáže nainstalovat Windows, ale z nějaké příčiny je nechce. Teď ale nevím, co bych mu nabídnul.

Taky jsem po letech zlenivěl a hledám něco do čeho neteče každej druhej den x+1 aktualizace. Váhám mezi Debian Squeeze (který se pomaličku blíží ke zmrazení) a CentOS 6 (pokud se zvěsti o release date alespoň trošičku blíží realitě). Pro Debian mluví balíčky linux-image-2.6-amd64 a nvidia-kernel-2.6-amd64 v i386 repositáři. CentOS boduje ještě delší podporou, aktuálnějšími nvidia ovladači v ELRepo a 3rd party yum repositáři (Go-oo, Adobe, Google (pro Debian pouze Google *)). Dovedl bych si představit i CentOS 5, který ale má několik málo balíčku opravdu archaických: Firefox je stále 3.0 (3.6 v 3rd party repositáři), Chromium (případně Google Chrome) vůbec není k dispozici a hlavně Gimp je pořád ještě 2.2.

* - Hádám, že chromium-browser se do Squeeze asi nestihne dostat...? Takže buďto Google Chrome, nebo z PPA pro Ubuntu.

[kyytaM]

OpenOffice je v Debiane standardne ako Go-oo mutacia. ;)

[Václav Kramář]

Vím. Narážím spíš na aktuálnost. Až dojde ke zmrazení a následně stabilizaci, tak už se tam novější verze dostane leda tak přes backports. Přidáním Go-oo repositáře dostanu stále aktuální verzi aniž bych ohrozil stabilitu celého systému. Ty 3rd party repositáře mě přiblíží k ideálu stabilního a konzervativního jádra systému (kernel, knihovny, X, DE,...) a zároveň aktuálních uživatelských aplikací (prohlížeč, office,...).

[Jakub Lucký]

na to by mohl stačit Stable-testing-unstable Apt-pining

[Václav Kramář]

Go-oo repo je ještě trochu aktuálnější a hlavně neobsahuje nic jiného než jenom office. Testing/unstable by mohl aktualizovat i některé závisloti a to nechci. Asi si to testnu ve virtualu, ale zatím se mi víc zamlouvá kombinace CentOS + 3rd party. Škoda, že zatím není známý release date.

Díky za tipy.