Názory k článku GConf: konfigurace GNOME pod kontrolou
-
viac som z clanku precitat nemusel a zdvihla sa mi zlc. specialne v gnomocentrickych distribuciach ako debian && ubuntu…
veci ako hal, d-bus a ponovom package-kit, device-kit (koniec koncov uz nakonfigurovat udev je maly salamunsky zakrok) su v pohode rucne editovatelne?!
to, ze je nieco textovy konfigurak, este neznamena, ze to leckdo bude bezne rucne editovat. tieto moderne gnomocentricke desktopove demony su rucne prakticky neskonfigurovatelne a ked sa v nich nieco rozsype, aj sebezbehlejsi uzivatel nema vela sanci s tym nieco narobit.
-
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.
-
Lol Phirae (neregistrovaný)
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/consolekit, to je potomek nesmyslu zvaneho pam_console, ktery nikdy spravne nefunguval a co mohl, to rozbil – o jeho nasledovnicich to plati mnohonasobne vic.
-
Lol Phirae (neregistrovaný)
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> -
HKou (neregistrovaný)
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.
-
m. (neregistrovaný)
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?
-
Lol Phirae (neregistrovaný)
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.
-
HKou (neregistrovaný)
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ě.
-
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?
-
m. (neregistrovaný)
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:)
-
Lol Phirae (neregistrovaný)
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á.
-
m. (neregistrovaný)
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.
-
HKou (neregistrovaný)
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.
