Vlákno názorů k článku
Nejzajímavější novinky v chystaném GNOME 3

Having all of the keys in a single compact binary format also avoids the intense fragmentation problems currently experienced by the tree-of-directories-of-xml-files approach.

Že bychom nakonec k těm windowsáckým registrům přece jen došli? Už se těším, co se stane, když se ten jediný velký binární soubor pokazí.

Chce se mi plakat...

Je to smutne ...

Naopak, je to pozitivní zpráva.

Dříve byla GConf databáze složená ze stovek konfiguračních souborů. Bylo to zoufale pomalé na čtení. Tak všechny volby slili do jediné XML databáze. Čtení je sice o trochu rychlejší, ale instalace GNOME se rázem protáhla o půl hodiny na tisíceré přechroustání konfigurační XML databáze.

A tako po letech konečně vývojářům došlo, že XML databáze není ideální databázový formát, ale slepá ulička. Binární databázové knihovny jsou řádově rychlejší než jakékoliv XML, a tak se dnes vrací tam, kde před deseti lety začínali - konfigurační knihovna s binárním databázovým back-endem.

aha a jak já já jako uživatel upravím?:D nehledě na to, předělávat něco co funguje dobře je nesmysl a hlavně když se něco pokazí v binárním souboru, jak to mám já jako uživatel upravit?
imho měli spíše ty soubory nějak sjednotit aby jich nebylo tolik a nechat xml..
jinak je vidět jak lze s xml pracovat přímo na Rhythmboxu, lehký, zvládá x-tisíc písniček v xml databázi naprosto bez problémů...

Už jste někdy přímo editoval gconf XML databázi? Zjistil byste, že to většinou nefunguje. GConf démon si totiž vytváří několik úrovní cache a vaše změny často ignoruje. Od editace je gconftool-2.

Ostatně ani SQL nikdo needituje přímo, a přesto to nikdo nepoužívá jako argument proti SQL databázím.

GConf soubory slili už v GNOME 2.24 (gconf-merge-tree). Výsledkem je mírné zrychlení čtení a řádové zpomalení zápisu. Prodloužení instalace GNOME zhruba o půl hodiny je pak jen jeden z vedlejších efektů.

Předělává se tedy něco, co nikdy pořádně nefungovalo.

U záložek epiphany nebo na rhythmbox je vidět, jak je XML neohrabaný databázový formát. Při startu rhythmbox nad 16GB SD kartou na mém PDA mohu začít přehrávat zhruba za pět minut. Konkurenční software s binární databází to zvládne za dvě sekundy.

Ano, čím více aplikací si ukládá svoje nastavení do jednoho (ještě k tomu binárního) souboru, tím lépe. Když pak jedna jediná něco zmrší při ukládání svého nastavení, mají ostatní zřejmě smůlu...

PS: A pak ta zábava, když po odinstalování aplikace tato po sobě neuklidí vše. A registry kynou a kynou.

Firmy jako Oracle si to asi nemyslí. Jinak by nekupovaly mySQL, která tabulky ve formátu klíč/hodnota ukládá do jednoho (ještě k tomu binárního) souboru. Only totiž existují metody, jak tento soubor pokud možno nezmršit.

Úklid v uživatelském prostoru po odinstalované aplikaci patří ke slabým stránkám UNIXu obecně. GConf není výjimkou. Pokud by to nový systém řešil, bylo by to jedině dobře.

Já se ale NEBAVÍM o formátu ukládání dat v nějaké databázi, to je mi teď šumafuk.

Já si jen myslím, že mít na správu konfigurací systému a aplikací jeden binární soubor a nějaký databázový stroj k tomu, je možná zbytečné.

Není, je to nejrozumnější způsob, jak efektivně poskytnout strukturovaná konfigurační data. Byly to právě mobilní platformy (např. GPE), které začaly na desktopu ukládat svá data do databází, a k případné ruční editaci používat SQL.

GConf databáze postupně nabubřela téměř k 50MB, a to je na XML databázi příliš i na rychlých strojích. Je jednoznačně největším zdržovačem jak při instalaci, tak při startu GNOME. Jsou dvě cesty, jak se s tím vypořádat:

- Změnit její implementaci a systematicky z ní vyházet překlady, které v ní tvoří přes 90% dat.

- Změnit její formát na ověřený binární databázový formát, neboť XML a textový balast tvoří dalších 70% ze zbytku. Tato změna navíc přinese index pro rychlé nalezení správného klíče.

Implementace obou zároveň přinese zrychlení možná o 3 řády.

To je fšechno poměrně fajn. Ale ještě lepší by bylo kdyby v Linuxu existovalo nějaké jednotné (a respektované) konfigurační rozhraní, které by tyto problémy řešilo nezávisle v samostatném projektu a ostatní projekty jej už jen využívaly. Myslím, že něco takového Linux potřebuje jak "koza drbání"... :)

Jéžiši. ten freud dneska řádí : s/fšechno/všechno

Freude, Freude, Freude,
vždycky na Tě dojde ...

Nerozumim pul hodine a tisiceremu prechroustani. My necachujeme disk? Nevim jak gnome, ale me se da casto pristupovany file do pameti a nic nikde nechrousta...
A laicky - kdyz uz by parsovani melo byt tak vypocetne naroce - co mi brani mit agenta, ktery to jednou secte, vytvori svou cache na bazi sql treba a pracuje na dotazy jednotlivych klientu?

Proste - registry jsou pro me jako nestovice. Mel jsem je jednou, kdyz jsem byl malej a uz je proste nechytnu.

Hlavní příčinou pomalosti není rychlost disku, ale parsování 46MB XML dat pro každou sadu klíčů.

gconfd-2 jako agent funguje pro uživatelské účty. Instalační skripty však používají --direct, tedy přímou modifikaci databáze bez mezistupně v podobě žurnálu a dalšího démona. Má to dobrý důvod - uživatelský démon by se musel dívat do žurnálů i u dat, která jsou pro něj pouze ke čtení, nebo se dotazovat superuživatelské instance gconf démona. Ani tak však gconf --direct nefunguje příliš dobře - superuživatelské změny se nepromítnou do cache uživatelských démonů okamžitě. To může způsobit i pád aplikace (nebo v nejhorším případě dokonce její trvalou nefunkčnost, jak tomu bývalo u apletu na sledování systému, kdy se místo implicitních hodnot ze systémové databáze dostaly do uživatelské databáze nuly).

Pokud vytvoříte cache na bázi binární SQL databáze, je vám její kopie ve formátu XML naprosto k ničemu. Ba co víc, škodí. Jde jen o mnohonásobně rozvleklejší reprezentaci téhož, ve které však musíte kontrolovat případné změny a řešit vznikající race condition (aplikace změní databázi, uživatel XML obraz; kdo má přednost?).

No, nemam nijak za cil poucovat vyvojare gnome. 46 MB konfiguraci je slusny cislo. Icewm ma 30kB, kdyby to bylo v xml, tak to da 60kB. Takze proste gnome je zrejme 500x lepsi, nebo alespon 500x konfigurovatelnejsi.

Jenze icewm je pouze window manager, nikoli desktop. Na urovni icewm je v gnome metacity, coz je defaultni window manager v gnome. Porovnavej porovnatelne. Metacity 46 MB cfg soubor nema.

Když už, tak Metacity + Gnome panel vs. IceWM. ;-)

Pomalost při chroustání 46 MB není ten opravdový problém. Tím je přítomnost 46 MB uživatelské konfigurace v jednom souboru. Ať se na to koukám jakkoliv, pořád mi vychází, že je to naprosto absurdní hloupost. Kde se tolik konfigurace vezme?

Obsah klíčů je: klíč (XML je hierarchicky uspořádaný), datový typ, datum modifikace, obsah klíče, asociace se schemas (jakési šablony pro tvorbu klíčů). Nedílnou součástí je popisek a nápověda pro každou volbu.

Více než 90% jsou pak překlady popisků a nápověd do všech jazyků. V poslední verzi sice nejsou ve stejném souboru, ale v souborech podle jazyků, nicméně instalátoru to nepomůže a stejně musí projít všechny.

Zbytek je XML-nutný balast a tabulátory pro hezké formátování.

Zřejmě chybný návrh.

Nicméně celkový počet klíčů v hlavní GConf databázi se na průměrné instalaci pohybuje kolem 10000, a průměrný počet databází v cestě je pod 10 (povinné klíče, klíče definované administrátorem, implicitní klíče, klíče definované dodavatelem, klíče pro lock down, uživatelské klíče). I tak je to dost na XML nebo holý text.

Ak je problem xml, lebo je pomale, podme na DB. ked DB nevyhovuje, lebo neumoznuje modifikaciu za pomoci napriklad dd -of=/dev/sda1..., tak podme na xml. Moj navrh, kusok sialeny na implementaciu, je taky, ze to dajme dokopy. Kde je problem mat xml databazu? Na disku to bude xml, ale nebude to na fat32, ani ext4 fs. Bude to na vlastnom oddieli, ktory bude plne kompatibilny s napriklad ext3 ale bezne sa bude montovat cez special fs modul, ktory bude udrzovat na danom fs dva subory. Jeden bude xml a druhy bude dane xml v databaze. Ked sa daco v xml bude menit, modul to updatne i v binarnej verzii s indexami. Ak niekto namontuje dany fs cez normalny ext3 modul, uvidi dva subory. jeden xml a jeden cache.db, binarny. Ak zedituje xml, zmeni sa jeho datum editovania a pri montovani cez original modul, bude cache updatnuta nanovo, co kus potrva...

Viem si vsak predstavit asi i kusok jednoduchsie riesenie, ale tamto sa mi zda technologicky pekne :-)

Databáze se vždy modifikuje přes knihovnu nebo službu. Přímá modifikace je zakázaná, neboť otvírá možnost jejího poškození dvěma souběžnými požadavky.

Zavádět na cache XML souboru samostatný souborový systém je naprosto šílené (nutnost přeformátování disku, mít parser XML v jádře, implementovat nový (byť virtuální) souborový systému).

Navíc váš návrh neřeší zásadní problém: Kdykoliv někdo začne editovat XML, je třeba okamžitě (atomicky) zamknout i tu binární podobu a po uzavření XML zápisu jí přegenerovat. Pokud to neuděláte, zakládáte si na problémy při souběžné změně v obou databázích.

Nyní si představte situaci, kdy váš editor se během editace XML pokusí do databáze něco uložit. Dostal jste se do klasického deadlocku: Editor čeká, až XML uložíte a zavřete, jinak nemůže aktualizovat svůj konfigurační klíč. XML však uložit nemůžete, protože editor čeká, až si uloží svá konfigurační data do databáze.

Asi som nevysvetlil moj navrh dost jasne. Skusim objasnit.

V pripade, ze dany novy FS bude namontovany vhodnym modulom, nebude ina moznost pristupu k tym datam, ako cez nejake specialne api, alebo cez upravu xml suboru, kde kazda aplikacia bude mat napriklad vlastny. Fyzicky to vsak bude vsetko ukladane do jedneho a zaroven bude updatovana databazova, binarna, verzia toho xml. Teda pri beznej cinnosti nebude dane subory vidno. Pouzivanie toho specialneho virtualneho fs by bolo jednoucelove, len pre uchovavanie nastaveni...

Jednoduchsia a menej sialena implementacia je teraz uz podla mna vsade pouzivana (neviem, ako to robi mac os x?). Je xml s nastaveniami, ktory je pristupny cez nejake api a to si riesi samostatne konkurentne pristupy a vsetko. V pripade padu systemu, nabootujem z livecd, par echo prikazov do vhodneho xml suboru, restart os a pri starte si natiahne dane data z xml a funguje dalej.

Spomienka o xml parseri v jadre je dobra a beriem ju ako jasny prblem pri mojom navrhovanom rieseni. To by bolo, aspon v dnesnej dobe, dost divne... Mozno v nejakom java OS by to slo :-)

PS: ak sa nemylim, pre xml subory (databazy v xml) je mozne vytvorit index tiez. Mozno i toto by bolo riesenie.

Toto upřesnění ovšem nijak nepředchází zmíněným problémům - pokud vygenerujete XML na editaci, musíte databázi zamknout, jinak bude systém náchylný k race condition. Navíc to znamená, že byste musel vytvořit zcela nové jaderné rozhraní na přímou manipulaci s onou databází.

Rebootovat kvůli každé změně nastavení, kterou chcete provést v XML, je sice řešením. Ale nevím, zda by se lidem líbilo. Doteď nebyl na změnu domovské stránky v prohlížeči reboot potřeba.

XML přístupné jen přes nějaké API, to je přesně současné GConf. Jenže pak je úplně jedno, je-li tv pozadí XML, binární databáze, souborový systém v jádře nebo třeba síťové úložiště. A to byla původní nenaplněná myšlenka GConf.

Proč backend implementovat složitě v jádře, když to jde jednoduše v uživatelském prostoru?

Abych to shrnul: Myšlenka API, výhradně kterou se mění konfigurace, je dobrá. Myšlenka ukládat tuto konfiguraci právě do XML, byla špatná. Myšlenka, že by mělo jít XML v pozadí editovat i přímo, bez použití nějakého API, by z toho udělala nepoužitelnou technologii. Myšlenka, že editace onoho XML by byla standardním postupem, by to znemožnila docela.

Pekne zhrnutie a musim Vam dat z casti zapravdu. Jedine co vsak asi cast linux userov drzi pri myslienke "nastavenia sa musia dat editovat cez vim!" je podla mna to, ze ked sa daco pokazi, netreba mat nic, len pristup na disk a vim. Teda, ze ked napriklad pokazim nastavenia vo fstab a po reboote system nenabehne, tak mam stale moznost nastartovat iny random linux z live cd a opravit to. V pripade binarnej verzie konfiguraku by bolo nutnost mat na to nejaky nastroj, co vie tu binarku editovat. Nepomoze ani riesenie, kedy bude ona toola pristupna v statickom builde dakde na stiahnutie. Nejde o technicky priblem, ale o mentalitu uzivatelov.

Ako riesenie by som videl socialne inzinierstvo :D Spravit GConf, ktory bude umoznovat ukladat nastavenia i do xml i do binarky (bud jedno, alebo druhe, nie naraz). Defoltne sa to bude davat do binarky a komu to bude vadit, tak si to prekonvertuje a bude ukladat v xml a bude spokojny. Casom sa pride na to, ze vela userov to nechalo v binarke (nechcelo sa im riesit,/nevedeli o tom) a prejde na to i zvysok sveta. Aspon by som to tak tipol ja, ale odhadnut swarm je tazke :-)

PS: skoda, ze tato diskusia je zbytocna. Sice mozno prideme k nejakemu zaveru/kompromisu, ale vyvojari sa k tomu asi nedostanu :-/

Je to jen o mentalitě. Jediný faktický rozdíl by byl v tom, že na záchranném systému by musel být třeba databázový nástroj. V případě trochu lepší databáze by náprava špatné konfigurace byla ještě jednodušší. Prostě by se provedl roll-back k poslední fungující konfiguraci.

GConf vypadal před 12 lety přesně tak, jak píšete - měl dva backendy - DB2 and XML. Jenže ten DB2 postupem času zanikl. Uznávám, Berkeley DB2 byla velmi špatná volba - u této databáze jste si nikdy nebyli jisti, že příští verze nebude mít jiný binární formát dat a jiné API.

Takze znovuobjavovanie objaveneho? :-) Som kusok mladsi a linux nie je mojou silnou strankou. Danu vec nepoznam. Aktualne vsak mam taky pocit, ze problem je v nesystemovosti riesenia... Gnome bude mat vlastne "registre", nastavenia, a KDE vlastne, kazdy java programcek bude mat vlastny sposob na ulozenie si svojich veci...

No nic, kriza softveroveho inzinierstva je tu a naplno prekvita :-)

Dakujem za informacie a nazory. Vcelku zaujimavy a prinosny "pokec".

Ne tak úplně. Myšlenka GConf byla dobrá, jen její realizace byla problematická: Překlady v databázi s konfigurací, nutnost démonů pro každého uživatele, jediný neefektivní funkční backend a závislost na CORBA. Proto příchází DConf.

GConf má například spoustu unikátních vlastností - konfiguraci lze snadno ukládat na více místech souběžně - můžete tedy mít to, co chtěl upstream, to překrýt tím, co nastavil váš dodavatel, to překrýt tím, co chtěl váš administrátor, a to překrát tím, co chcete vy. To velmi zjednoduší upgrade - vše, co jste si upravili, zůstane zachováno, a to bez slévání textových souborů s nejistým výsledkem.

Naštěstí zde máme freedesktop.org, které se snaží o sjednocení přístupů všech částí systému. Některým jejich výstupům se dostalo širokého přijetí (D-Bus, Shared MIME Database, Desktop soubory, HAL), jiným méně (MIME Actions). Některé sami tvůrci časem opět označili za špatně vymyšlené (HAL).

Přestože je to běh na velmi dlouhou trať, je zde cítit pokrok.

Nedá se to tak udělat:

1) Většina editorů XML si nezamyká text pro celou dobu editování. Paralelní změna editovaného souboru během práce způsobí u lepších editorů varování (které není radno ignorovat), u horších editorů ztrátu dat.

2) Pokud tak učiní, a samy jsou klientem konfigurační databáze, způsobí při prvním pokusu o přístup do databáze dead lock.

Semafory zvyšují nároky na programátora - musí si pamatovat, že před každou operací si povinně musí databázi zamkout. Pokud na to jeden jediný programátor zapomene jen na jednom jediném místě, může se stát, že se občas poškodí obsah celé databáze.