Vlákno názorů k článku
GConf: konfigurace GNOME pod kontrolou

Clanecek pekny (az na nechapajici uzivatele, kteri si museli ulevit v diskuzi, viz. vyse), ale docela spatne nacasovany. Za dvermi tu totiz mame GSettings a dconf, ktery bude doufam brzy mergnut do platformy (Gnome). Ale pravda je, ze GConf bude jeste zit, alespon do letosniho podzimu.

http://live.gnome.org/dconf

Ja doufam, ze nebude. Ukladat konfiguraci binarne mi neprijde jako dobry napad.

Presne tak. Prejst k binarnej forme je jedna z najvacsich chyb pre akykolvek program na GNU/Linuxe aspon teda v mojich ociach. Urobil to tak Enlightenment a prestal som ho pouzivat.

Binárně? V článku je napsáno (a sám jsem si to teď ověřil), že data v adresáři .gconf jsou uložena v XML. Kde je tedy to binární úložiště (ptám se vážně)?

Ano, gconf pouziva XML, coz se da v nejhorsim pripade editovat rucne. Binarni DB pouziva zminovany dconf (s/g/d/). Pouzivam spript sestavajici se ze sekvence gconftool-2 volani, ktera priohnou gnome k obrazu memu. Klikaci nastroj pouzivam jen k hledani tech spravnych klicu (1×), nicmene mam stale rad moznost videt do XML konfigurace, proto ne dconf.

dconf- policykit integration…all of the keys in a single compact binary format… uz to vidim.
Nelezi nekde pdf, kde se ukazuje, kolik plati user za to, ze je to v xml? Mozna, ze jde o par vterin na zacatku a kvuli tomu se ma dobit uz takhle kostrbaty system? Icewm (chapu, ze tu nejsem uplne spravne) ma par textovych filu, pri zmene dam restart manageru (2 sekundy) a svistim.
Moje zpatecnictvi je az takove, ze se ptam, ma smysl sem cpat xml? Nestacil by jen text?

2 sekundy u jednoduchého prostředí jsou celkem hodně, GNOME je větší, takže když se 2 sekundy vynásobí 5… už to začne být problém. V GNOME trvá přihlášení dlouho. Ve Fedoře při prvním přihlášení se prostředí startuje přes 20 sekund, další přihlášení už je mnohem rychlejší. Zřejmě se teda načtené nastavení kešuje a má to velký vliv. Nebylo by teda lepší, kdyby gnome-settings-daemon na začátku rychle sekvenčně přečetl všechny nastavení a pak je držel v paměti? Nemuselo by se skákat po disku, což při startu GNOME nejvíc zdržuje [ http://people.gnome.org/~lcolitti/gnome-startup/analysis/ ].

Zapisuje se zřídka, takže to by nemusel být problém; i když s rozsáhlým nastavením by přepsání celého souboru (kvůli sekvenčnímu čtení by to muselo být všechno v jednom souboru) mohlo být neúnosné. A tady se zrovna hodí databáze: čtení a zápis do struktury je mnohem rychlejší. Textové soubory prostě nejsou na ukládání stromu vhodné. Kdyby se dconf na nějaký efektivní přístup ke strukturovaným nastavením vykašlal a prostě by se na všechno použily textové konfiguráky, mohli by to rovnou zabalit – na to není potřeba speciální služba. Každá aplikace by si udržovala ty svoje a navzájem by nekomunikovaly. S Gconfem není potřeba restart, změny se projeví okamžitě. Je to něco za něco – efektivní uložení strukturovaných dat pro počítač a zároveň přímo čitelné pro člověka neexistuje.

Ano, ano. Kazdy uzivatel startuje window manager 100× denne, takze mu to zaberie denne 15 minut a to my nechceme a radsej do vsetkoho zaprasime databazu, najlepsie sqlite…

ps: pocitac uspesne uspavam a keby som ho aj startoval kazdy den, tak par minut je fakt zanedbatelnych oproti celodennej praci

Nejen při startu, ale i při každé změně se to bude načítat. Když bude všechno v textovém souboru, bude se ten soubor při každé i drobné změně celý přepisovat. Ještě by se ten soubor musel nějak hlídat, aby se nastavení aktualizovalo, když se v něm někdo pohrabe textovým editorem nebo by se pak musel dát povel k znovunačtení (jako u IceWM restart). Jak by to teda mělo fungovat?

Aaaano, velky problem, napr. pres inotify. No ale co cekat od Gnome shitu.

Jo, inotify je mezi vyvojari hromadne nazyvan PITA, taky jsem na nem bohuzel neco delal a je to opravdu bolest. Tady cesta nevede, ceka se na fanotify, ale v puvodnim dotazu je jakekoliv pouziti notifikacniho systemu protichudne.

No, opravdu nevim co k tomu podotknout. Jestli nekudy cesta nevede, tak je to srani konfiguraku do binarniho blobu.

OK, ocekavam tvuj prispevek v desktop-devel-listu, abychom se mohli zacit bavit na rozumne urovni (a vynechame nepodlozene nadavani v diskuzi pod clankem).

http://mail.gnome.org/mailman/listinfo/desktop-devel-list

A jaky prispevek presne ocekavas? Ze XML saje, ale binarni blob saje jeste daleko vic a jako cena za jakesi pofiderni zrychleni prvniho spusteni Gnome je to uplne postavene na hlavu, to uz tady bylo nekolikrat napsano. Fakt nevim, co bych k tomu jeste dodal. Az se ten binarni krap nekomu posere, jako je to celkem bezne u Windows registru, tak proste nastavi vsechno odznova a vyreseno, ze? A az se posere globalni konfigurace, staci preinstalovat komplet Gnome plus vsechno dalsi, co si do toho kramu bude ukladat konfiguraci. Vyhodou oproti Windows jeste porad je, ze nebude muset preinstalovat cely system. :P

To je opravdu kouzelná země, kde duch unixu je věčný a všudypřítomný, všechno je čistý textový soubor a binární blob vždycky saje víc. XD

To myslíš vážně? Je přece jasné, že hloupý textový soubor se kvalitnímu formátu přímo navrženému tak, aby se v něm dobře dělaly ty operace, které jsou v něm potřeba dělat, nemůže rovnat. Textový soubor saje víc, v některých případech daleko víc, tak moc, že se prostě nedá použít. Co takhle implementovat tabulku o miliónech řádků nebo podobně velký strom, kde se bude vyhledávat, jako prostý textový soubor (žádné indexy, žádná fragmentace – nic). Je jasné, že se to tak udělat nedá.

Nejde jenom o to, načíst při startu GNOME nějaké konfiguráky a tím by bylo hotovo. Používá se to i za běhu. Když se ten binární křáp posere, tak to snad půjde spravit specializovaným nástrojem určeným k manipulaci s tím binárním křápem, akorát na to nebude stačit obyčejný textový editor. Jestli bude kvalitní nástroj k dispozoci je otázka, doufejme, že ano. V čem je jinak lepší, když se místo binárního posere textový křáp?

Nápady v GNOME 3 (vyžadování HW akcelerace, neprakticky vypadající GNOME shell, lišta nahoře jen k vysouvání nějaké centrální nabídky atd.) se mi moc nezdají, ale zrovna že chtějí zrychlit start je dobře.

Necht binarni krap je treba soubor .doc a specializovany editor na nej je Word (nebo sxw/oo) vs. textovy soubor se zdrojakem v TeXu. Dalsi analogie je treba SVG, ktere se da v nouzi editovat rucne (nebo Postscript) vs. fig/PDF.

Nehlede na to, ze na opravu textovych konfiguraku se da pouzivat diff, patch, atd., pokud je system poskodi. Snad nebude mit konfigurace Gnome milion radku.

Určitě, když není důvod zavádět binární křáp a stejně dobře poslouží i obyč. textový soubor, tak je lepší zůstat u něj. U systému, kde různé aplikace v reálném čase přistupují k nastavení a změny se musí okamžitě projevit (aplikaci, co jí to nastavení patří, se zavolá funkce), tam by prostě mohl být texťák hodně neefektivní. Nějak to i tak zatím zvládli s XML, ale je to zřejmě dost pomalé.

Gconf není jenom konfigurace Gnome, je s ním spojený démon, co slouží jako takový server pro konfiguraci. Takové věci by měly být naprogramované efektivně a spolehlivě.

Ano, gconf jako konfiguracni server, tot sen kazdeho linuxaka. Skoro jako regedit. A az to bude v binarnim krapu, tak to bude uplne dokonale. Jen bacha, aby vam Bill se Stevem nezalovali za obslehnuti toho nejhorsiho, co Windows vyprodukovaly. :P

Texťák se dá jednou načíst, přechroupat do přijatelné (binární) podoby a po skončení přechroupat zase zpátky. Není dělaný na to, aby se v něm pořád něco dělalo. Chceš, aby to takhle fungovalo? Taky to jde, pak ale pád znamená ztrátu nastavení. To je zvlášť příjemné, když tak rád uspáváš :) Firefox kvůli tomuhle přešel na sqlite.

technická: příspěvky se pořád zužují a zužují… až z nich nezbude nic (jako na abclinuxu.cz). proč se kurňa nemůže ta stránka roztáhnout?

Ano, Firefox presiel na sqlite a preto si stale robi zalohu zaloziek do textovej podoby :D

ps: pokial bude existovat textovy konfigurak, kde sa bude pravidelne ukladat zaloha, tak s tym nemam problem. Ale verit v modlu dokonaleho editora, ktory by zachranil nastavenia v binarnej podobe je pekny nezmysel. Zmena jedineho bitu a nastavenia mozem vyhodit. Samozrejme pokial tam nebude nejaka redundancia a opravne kody:)

Ano, FF to je zarny priklad… vyexportovat cookies a naimportovat je jinde, to je problem, ktery nikoho nezajima. Zkopirovat jeden textovy soubor bylo moc jednoduche, takze ted to pro jistotu oficialne nejde vubec, dokonce ta funkce (kterou ma i pitomy MSIE) naprosto zmizela z menu. Hura! Navic soudruzi z Mozilly zjistili, ze jaksi sqlite defaultne nic nemaze, a protoze vsichni maji v prohlizeci supertajna data, tak po upgradu FF proste odmitl fungovat s tim, ze systemove sqlite nepodporuje secure delete. Uzasne!

Redundance a opravné kódy už jsou na úrovni filesystému. I tak je to dobrý nápad. Stejně tak záloha. S tím, jak je možné použít i jiný backend, by to neměl být problém.

Firefox zálohuje záložky ze sqlite do JSONu nebo HTML (obojí textový formát), je to celkem logické. Že totéž nenabízí i u cookies je samozřejmě chyba. Se záložkama není přenášení problém.

Databáze obecně považujete za špatné? Zase třeba u PHP se často používá databáze na všechno, přestože spojení PHP s MySQL strašně zdržuje a při každém requestu se vytváří znovu. Spíš to je humus a stejně se to dělá.

Uz vidim bezneho uzivatela, ktory ma na svoj domovsky adresar nasadeny aspon softwarovy raid :)
Mne je osobne jedno v akom formate to ten program ma. Ide mi o to, aby existovala textova podoba tej konfiguracie, ktoru by som si mohol upravovat, zalohovat, posielat kamaratom a do diskusii, jednoducho patchovat.. a samozrejme ked to padne na drzku, tak je jednoduchsie zachranovat textovy konfigurak kvalitnym textovym editorom ako zachranovat binarny konfigurak jedinym existujucim editorom. Uviedol som priklad Enlightenmentu, ktory ma vsetko v binarnych suboroch a to ma stve, ze ani tie blbe klavesove skratky si nemozem jednoducho nakonfigurovat a to uz ani nehovorim o upgrade alebo zmene verzie.
Pokial sa databazy pouziju na to, na co su urcene a to pre velky objem dat. PHP a MySQL je uplne ina tema. PHP je vhodne na male IS a MySQL zase na male jednoduche databazy. A ze to niekto pouziva nespravnym sposobom nie je chyba technologie, ale tvorcu toho programu.

GSettings bude mit moznost modularnich backendu, dconf je jen jeden z nich, defaultni. Takze neni problem pouzivat neco jineho, kdyz se to uzivateli nelibi, z vykonnostnich duvodu bych ale radeji videl binarni formu, soucasna struktura XML je silene pomala.

Ze zkusenosti vim, ze binarni databaze, jak jsou delane v gvfs-metadata-daemon jsou celkem spolehlive, az na porodni bolesti. AFAIK desrt planuje pro dconf neco podobneho, multiple non-blocking read access a unikatni daemon pro zapis + zurnal.

Me by se libilo mit textove konfiguraky (celkem je jedno, jestli v XML nebo ne, radsi ne v m4), demona, ktery at to klidne samostatne prechroupava do binarni databaze s rychlym pristupem pro cteni konfigurace. Prece nejde o to, aby se se zmena projevila okamzite, ale aby pristup ke konfiguracim nebyl pomaly a to resitelne je.

Bude podpora aj takych backendov ako Berkeley DB?

Jo, to by bylo idealni. Takova vec, ktera ma asi 20 vzajemne nekompatibilnich verzi je pro ukladani konfigurace jako delana! :-D