Názory k článku
GConf: konfigurace GNOME pod kontrolou

Chudak autor – bude ted dostavat z obou stran. Jsem rad, ze tu o tom pise. I kdyz nesnasim vsechny tyhle kity, co se nesmyslne vyrojily, aby napodobily windows a gnome zacina mergovat na gnondows (napr.bug v pulseaudio mi srazil radu dalsich aplikaci, bug v gdm mi vyradil multiuzivatelsky desktop), porad existuji pod gnome silne a uzitecne aplikace, ktere pouziji ve svem light wm. Debian je zatim ostrovem proti masovemu testovani kitu na lidech, takze i kdyz me to stalo usili, zakormidloval jsem timhle smerem.

Ano, hal a spol. se zvlast povedl. X server s velkou slavou od toho krapu zdrha a prechazeji na udev (k videni jiz naostro napr. ve Fedore 13. Posledne jsem potreboval povolit trojhmat pro zabiti X a malem jsem u toho porodil jezka, na zabiti! DontZap zrejme nebylo dost cool, takze ted mame po nekolika hodinach tohle a nejakym zazrakem funguje jak prepinani klavesnic, tak zabijeni X serveru:

<code>>
<<?xml version="1.0" encoding="UTF-8"?>>
<<!--
See http://cgit.freedesktop.org/xorg/xserver/plain/config/x11-input.fdi
-->>
<<deviceinfo version="0.2">>
   <<match key="info.capabilities" contains="input.keyboard">>
      <<merge key="input.x11_options.XkbModel" type="string">>evdev<</merge>>
      <<merge key="input.x11_options.XkbLayout" type="string">>us,cz<</merge>>
      <<merge key="input.x11_options.XkbVariant" type="string">>,qwerty_bksl<</merge>>
      <<merge key="input.x11_options.XkbOptions" type="strlist">>terminate:ctrl_alt_bksp<</merge>>
      <<!-- This used to be one fucking simple line in xorg.conf
      Section "ServerFlags"
            Option DontZap "False"
      EndSection
      Yes, it's a lot "better" and "easier" now with HAL! Argh!
      -->>
      <<append key="input.x11_options.XkbOptions" type="strlist">>grp:alt_shift_toggle<</append>>
      <<append key="input.x11_options.XkbOptions" type="strlist">>grp_led:scroll<</append>>
      <<append key="input.x11_options.XkbOptions" type="strlist">>compose:ralt<</append>>
   <</match>>
<</deviceinfo>>

Policykit/con­solekit, to je potomek nesmyslu zvaneho pam_console, ktery nikdy spravne nefunguval a co mohl, to rozbil – o jeho nasledovnicich to plati mnohonasobne vic.

Cteny ctenar si odmysli zdvojene zavorky, proste jsem nemel naladu dal bojovat s „inteligentnim“ chapanim tagu <pre> a <code> v podani Krcmarovych studentiku ze Zizkova, co to vyrobi si muzete ostatne vyzkouset sami. :(

Ano, tak si to zkus.

	
   
		
      
			evdev
			
      
			us,cz
			
      
			,qwerty_bksl
			
      
			terminate:ctrl_alt_bksp
			
      
      
			grp:alt_shift_toggle
			
      
			grp_led:scroll
			
      
			compose:ralt
			
   
		

V cem je problem je snad jasne videt. Muze si to vyzkouset kazdy, kdo tu prvni ukazku zbavi nadbytecnych zavorek a zkusi ji sem pastnout v tagu <pre> Ze to zvladne jedna dva tri ctyri pet, cos to Janku cos to sned', to je sice pekne, ale na jednoduchem xml souboru si to uplne vylame zuby.

Ale nic si to nevyláme. Normálně to funguje:

<?xml version="1.0" encoding="UTF-8"?>
<!--
See http://cgit.freedesktop.org/xorg/xserver/plain/config/x11-input.fdi
-->
<deviceinfo version="0.2">
   <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.x11_options.XkbModel" type="string">evdev</merge>
      <merge key="input.x11_options.XkbLayout" type="string">us,cz</merge>
      <merge key="input.x11_options.XkbVariant" type="string">,qwerty_bksl</merge>
      <merge key="input.x11_options.XkbOptions" type="strlist">terminate:ctrl_alt_bksp</merge>
      <!-- This used to be one fucking simple line in xorg.conf
      Section "ServerFlags"
            Option DontZap "False"
      EndSection
      Yes, it's a lot "better" and "easier" now with HAL! Argh!
      -->
      <append key="input.x11_options.XkbOptions" type="strlist">grp:alt_shift_toggle</append>
      <append key="input.x11_options.XkbOptions" type="strlist">grp_led:scroll</append>
      <append key="input.x11_options.XkbOptions" type="strlist">compose:ralt</append>
   </match>
</deviceinfo>

	
   
		
      
			evdev
			
      
			us,cz
			
      
			,qwerty_bksl
			
      
			terminate:ctrl_alt_bksp
			
      
      
			grp:alt_shift_toggle
			
      
			grp_led:scroll
			
      
			compose:ralt
			
   
		

Cut'n'paste vyse uvedeneho „nevylamaneho“ textu. Nevim, co bych k tomu jeste podotknul. Mas to rozbity, tecka.

uff dikec, co já se u toho navztekal..

Lutych.

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?

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

Potřeboval jsem přidat trvalou konfiguraci do svého řádkového programu. Uvažoval jsem o gconfu. Když jsem ale zjistil, že potřebuje GTK a dbus, tak jsem raději zvolil knihovnu confuse.