В Виндовсе они все одновременно в памяти хранятся. Иначе бы их реестр не хаяли :)

>В Виндовсе они все одновременно в памяти хранятся.

Вообще-то нет.

Плох своей неудобностью. Он - среднее, между юзабельным интерфейсом и текстовыми конфигами. Ни рыба, ни мясо.

Например чтобы поработать с настройками десктопа нужно как минимум залезть в несколько подкатегорий, например в display и в настройки наутилуса, затем ещё куда-нибудь и так далее. Нету логичной структуры.

Также он нехорош тем, что многие вещи можно поменять только через него, хотя они "просто просятся" быть в настройках гнома, в гуе. Получился графический редактор конфигов, довольно неудобный.

В общем, если его нормально допилить, то будет неплохая штука.

<no flame> Похожая на kcontrolcenter:) <no flame>

джиконф тоже периодически по памяти лазиет

> В Виндовсе они все одновременно в памяти хранятся. Иначе бы их реестр не хаяли :)

Сильно сомневаюсь. Ведь реестр-то большой, а памяти не очень много.

> В общем, если его нормально допилить, то будет неплохая штука.

Ну, значит идея действительно неплоха, спасибо.

> Нет, правда. Чем GConf действительно плох?

Ему нужен питон.

> Приложения хранят свои настройки не в горе каких-то своих конфигурационных файлах, а в виде, который предусмотрен бэкэндом gconf, то есть (в большинстве случаев) - в виде XML-файлов, которые можно редактировать и без gconf-editor.

Их нельзя редактировать стандартной связкой sed/grep/awk.

> Ну и что, что в Windows так же? Но ведь там нет возможности руками поправить нужные ключи, без regedit.

а как же hexedit? :)

> Мне кажется, что всё это очень даже неплохо...

Никто не в силах объять необъятного(например, объять все варианты, которые возникают при хранении конфигов). Следовательно, все реализации, претендующие на всеобъемлющесть -- убоги и монструозны.

p.s. ksycoca тоже говно. ибо я не хочу грузить в память конфиги десятка приложений, запуская всего-навсего одну kate.

>>ибо я не хочу грузить в память конфиги десятка приложений, запуская всего-навсего одну kate.

Ы ??

> Ему нужен питон.

ммм, то есть, они не смогли написать gconf без использования петона?

> Их нельзя редактировать стандартной связкой sed/grep/awk.

кажется, это зависит от выбора бэкэнда? наверняка есть не только xml...

> Никто не в силах объять необъятного(например, объять все варианты, которые возникают при хранении конфигов). Следовательно, все реализации, претендующие на всеобъемлющесть -- убоги и монструозны.

тут согласен, хотя общие случаи предусмотреть возможно.

Re^2: Чем плох GConf?

>>>ибо я не хочу грузить в память конфиги десятка приложений, запуская всего-навсего одну kate.

> Ы ??

Иначе я не могу придумать, почему при старте возникают _такие_ тормоза!

Re^2: Чем плох GConf?

>> Ему нужен питон.

> ммм, то есть, они не смогли написать gconf без использования петона?

Наш официальный гномотролль говорит, что их можно оторвать. Но в дебиане gconf на питон жёстко ссылается.

>> Их нельзя редактировать стандартной связкой sed/grep/awk.

> кажется, это зависит от выбора бэкэнда? наверняка есть не только xml...

>> Никто не в силах объять необъятного(например, объять все варианты, которые возникают при хранении конфигов). Следовательно, все реализации, претендующие на всеобъемлющесть -- убоги и монструозны.

> тут согласен, хотя общие случаи предусмотреть возможно.

Ну так и оставить выбор за автором программы. Так нет ведь, заклюют за то, что не там данные хранишь :)

Re^2: Чем плох GConf?

>> Их нельзя редактировать стандартной связкой sed/grep/awk.

> кажется, это зависит от выбора бэкэнда? наверняка есть не только xml...

Интересно, какой бэкенд мне в удобном виде сохранит конфиг, в который понапиханы картинки, текст, звуки, цвета и куча чисел :)

> Интересно, какой бэкенд мне в удобном виде сохранит конфиг, в который понапиханы картинки, текст, звуки, цвета и куча чисел :)

А что, теперь хранить бинарные данные в отдельных файлах не круто? Лишь бы бэкэнд умел.

К тому же, это необычная задача. Зачем картинки в конфигах?

> Ну так и оставить выбор за автором программы. Так нет ведь, заклюют за то, что не там данные хранишь :)

Основые параметры (всякие там числа, строки, bool) хранить в gconf. Двоичные данные - либо в BLOB-полях (глупо), либо в каталоге с программой (хотя не очень логично).

Ничем он не плох. Просто gconf -> реестр -> венда -> говно, примерно такая ассоциация у красноглазых аналитиков.

Единственная проблема — это одно из узких мест в системе, и оно должно быть хорошо написано.

А зачем нужен gconf, если есть простые текстовые конфиги? Читать AoUP до полного просветления. Тем более он завязан на DE.

ЗЫ: xml для конфига в общем случае хуже, чем text/plain

> Интересно, какой бэкенд мне в удобном виде сохранит конфиг, в который понапиханы картинки, текст, звуки, цвета и куча чисел :)

Вы тяжело бредите. В конфиге это все хранится не может, если это нормальная программа. Конфиг - не место для всякой медии. Только строки (числа - как частный случай).

А урлы в конфиг запихиваются сколько угодно.

> если есть простые текстовые конфиги?

Затем что они создают бардак. Не поддаются контролю и учету.

> Тем более он завязан на DE.

На fd.o уже ведутся работы по развязыванию.

> ЗЫ: xml для конфига в общем случае хуже, чем text/plain

Ровно наоборот. Если нет жесткого соглашения о представлении иерархических структур в text/plain (но тогда чем оно лучше, чем уже стандартизованный xml?)

eveel> Приложения хранят свои настройки не в горе каких-то своих конфигурационных файлах, а в

...реестре :)

>Если нет жесткого соглашения о представлении иерархических структур в text/plain

Конфиги — всегда иерархические структуры? XML — хорошая вещь, если нужен единый формат конфигов (XML сложнее любого формата конфигов, но проще, чем их совокупность). Но все же XML гораздо сложнее редактировать вручную (не работает sed+frep+awk, в куче тегов сложно найти данные). Поэтому XML — вещь хорошая, но не везде. Текстовые конфиги дают больше возможностей. Да и комменты в том же gconf не встретить…

>XML — хорошая вещь, если нужен единый формат конфигов

Приведи пример, когда текст хуже XML.

> ...реестре :)

По сути - да. Но ведь зависит от реализации этого "реестра" =)

> Конфиги — всегда иерархические структуры?

Да. Плоский случай - частный случай.

> Текстовые конфиги дают больше возможностей.

Эти возможности не нужны для конфигурации. Да, если так дороги sed/grep/awk - всегда есть gconftool-2, который можно использовать для скриптования.

> Да и комменты в том же gconf не встретить…

Оппаньки. А то что приличные прикладухи запихивают (локализуемое!) описание каждого ключа - это ерунда? Вы часто видели текстовые конфигурационные файлы с комментариями на нескольких языках?

>>Приведи пример, когда текст хуже XML.

настройки в виде кода на LISP ? :)

>Приведи пример, когда текст хуже XML.

Каталог /etc. И весь зоопарк форматов, которые там обитают. xml хотя бы единый формат.

Вы слишком широко понимаете настройки. Если у Вас настройки должны быть скриптами (что весьма экзотично) - заведите свой приватный каталог и храните имена файлов в gconf

XML не панацея, он не определяет семантику, тебе так же придётся читать документацию по формату. Единственное от чего избавляет XML — от необходимости писать свой парсер разработчику. В этом есть и плюсы и минусы.

x3al> Каталог /etc. И весь зоопарк форматов, которые там обитают. xml хотя бы единый формат.

Почему?

>Эти возможности не нужны для конфигурации.

http://catb.org/~esr/writings/taoup/html/ch08s02.html#fetchmailrc

Что-то подобное в xml вообще и в gconf в частности нет смысла реализовывать. Человекочитаемый конфиг в xml делать сложнее. Для конфигурабельности не нужно. Но гораздо понятнее.

>А то что приличные прикладухи запихивают (локализуемое!) описание каждого ключа - это ерунда?

Много ли таких приличных прикладнух, которые еще и не поленились локализовать?

ЗЫ: кто-нибудь попытается перевести sendmail.cf в gconf?)

Многие юниксовые приложения это вообще небольшой фреймворк-конструктор, и конфиг для них — часть приложения. Про них речь не идёт. Речь идёт про какой-нибудь evince, которому нужно запомнить кучку галочек и положение окна.

>Почему?

Потому, что разобраться в одном формате проще, чем во всем зоопарке форматов. Впрочем, для некоторого софта прийдется оставить конфиг в plaintext ввиду специфичности + расчета на редактирование руками.

>Речь идёт про какой-нибудь evince, которому нужно запомнить кучку галочек и положение окна.

Для таких приложений gconf — вполне нормальное решение. Только топикстартер просил перечислить все недостатки gconf.

> Что-то подобное в xml вообще и в gconf в частности нет смысла реализовывать

Почему? Вполне укладывается.

> Человекочитаемый конфиг в xml делать сложнее

xml - только один из бекендов. И читается gconf xml довольно легко.

> Но гораздо понятнее.

Всяко бывает. См. тот же sendmail

> Много ли таких приличных прикладнух, которые еще и не поленились локализовать?

Весь гномовский десктоп - локализован в gconf. Строки из gconf так же входят в статистику локализации, как и строки из UI. А дальше смотрите статистику на гномовском сайте.

Любые другие приложения под gnome/gtk - точно так же легко локализуемы в области gconf.

уважаемый, привидите хоть один пример, того, что вы собрались редактировать в конфигах чере sed+grep+awk. Я вообще это с трудом представляю.

> Да и комменты в том же gconf не встретить…

Вы бы хоть раз gconf-editor запустили бы перед тем, что бы тролить.

gconf очень неплох, но его проблема в однопоточной реализации. При старте гномовской сессии он начинает получать гору запросов, обрабатывая их по очереди, что естественно замедляет загрузку DE.

Afaik единственный минус. Все остальное -- вполне на высоте. Еще вроде как кто-то грозился оптимизировать алгоритм поиска значений по все базе, но как по мне, так он и так вполне себе шустрый. Главное -- это добавить в gconf сервер многопоточную обработку запросов.

>Всяко бывает. См. тот же sendmail

В xml он не будет понятнее.

Никто и не говорит, что будет. Это Вы пытаетесь доказать, что в тексте все шоколадно и читаемо. Так вот нифига. И еще раз - в gconf главное не xml (всего лишь дефолтный бекенд), а интерфейс. Единый и стандартизованный. Чего у текстовых парсеров в помойке /etc (и $HOME/.*) нет и в помине.

> gconf очень неплох, но его проблема в однопоточной реализации. При старте гномовской сессии он начинает получать гору запросов, обрабатывая их по очереди, что естественно замедляет загрузку DE.

Моему тазику около 3-4 лет, но при старте гнома я почти не замечаю тормозов. Вроде всё весьма шустро...

ну, как говорится нет пределу совершенству. :)

Re^4: Чем плох GConf?

>> Интересно, какой бэкенд мне в удобном виде сохранит конфиг, в который понапиханы картинки, текст, звуки, цвета и куча чисел :)

> Вы тяжело бредите. В конфиге это все хранится не может, если это нормальная программа. Конфиг - не место для всякой медии. Только строки (числа - как частный случай).

Хм, а аватара у мессенджера? Тоже прикажете в отдельный файл выложить

?

Re^2: Чем плох GConf?

>> если есть простые текстовые конфиги?

> Затем что они создают бардак. Не поддаются контролю и учету.

Кому бардак, а кому -- разнообразие и возможность выбора.

>> ЗЫ: xml для конфига в общем случае хуже, чем text/plain

> Ровно наоборот. Если нет жесткого соглашения о представлении иерархических структур в text/plain (но тогда чем оно лучше, чем уже стандартизованный xml?)

А разбор xml уже есть в awk или shell? Тем он и хуже.

в base64 там всё что хошь может хранится :)

Re^2: Чем плох GConf?

>> Текстовые конфиги дают больше возможностей.

> Эти возможности не нужны для конфигурации.

Они нужны для удобства программиста. И юзера.

> Да, если так дороги sed/grep/awk - всегда есть gconftool-2, который можно использовать для скриптования.

Он есть в LSB? Нет. Тогда увы, на его наличие не приходится рассчитывать.

Кроме того, оно тянет за собой мерзкий питон.

>> Да и комменты в том же gconf не встретить…

> Оппаньки. А то что приличные прикладухи запихивают (локализуемое!) описание каждого ключа - это ерунда? Вы часто видели текстовые конфигурационные файлы с комментариями на нескольких языках?

Могу из вредности сделать :) Надо?

> Хм, а аватара у мессенджера? Тоже прикажете в отдельный файл выложить?

Во-первых - возможно и так. Если аватара не только у мессенжера, но и лицо для gdm и для разных других программ. Во-вторых - для мелких картинок base64 вполне сойдет (не говоря уж про svg!).

Re^2: Чем плох GConf?

> xml - только один из бекендов. И читается gconf xml довольно легко.

Какие ещё есть? Просто интересно.

Re^2: Чем плох GConf?

> Никто и не говорит, что будет. Это Вы пытаетесь доказать, что в тексте все шоколадно и читаемо. Так вот нифига. И еще раз - в gconf главное не xml (всего лишь дефолтный бекенд), а интерфейс. Единый и стандартизованный. Чего у текстовых парсеров в помойке /etc (и $HOME/.*) нет и в помине.

Этот единый интерфейс потянет за собой наличие библиотек подо все языки. Есть ли либы для работы gconf для tcl, shell, perl, lisp

и pascal?

Re^2: Чем плох GConf?

> уважаемый, привидите хоть один пример, того, что вы собрались редактировать в конфигах чере sed+grep+awk. Я вообще это с трудом представляю.

cat /etc/passwd | grep -v ^user: > /etc/passwd.new

или ещё:

sed -i /etc/default/bluetooth 's/^BLUETOOTH_ENABLED=\d+/BLUETOOTH_ENABLED=1/'

> Они нужны для удобства программиста. И юзера.

Для удобства программиста куда важнее единый удобный API - в терминах соотв. абстракций. Это я Вам как программист программисту. Для юзера текстовые конфиги почти всегда пофиг. Для 99% юзеров. Кому они реально нужны - это power users. Ничтожное меньшинство. Которому вполне хватит gconftool-2

> Он есть в LSB?

У Вас принцип такой - обсуждать что-то, даже не представляя о чем речь? gconftool-2 идет вместе с gconf. Так что если у Вас есть gconf - у Вас есть gconftool-2. Можете "рассчитывать на наличие". Про питон ничего не знаю - проблемы дистромейкеров предлагаю не вмешивать, давайте отделять мух от котлет.

> Могу из вредности сделать :) Надо?

Меня не интересует вредность. Меня интересует реальность. В реальности ни в одном из конфигурационных файлов в /etc я не видел комментариев на русском (кстати, не желаете ли обсудить, в какой кодировке должны быть эти комментарии?)

Re^6: Чем плох GConf?

> в base64 там всё что хошь может хранится :)

я не умею в уме рассматривать картинку, закодированную в base64. мне легче спроецировать восьмимерную сферу на двумерную плоскость

А выгрузка в отдельный файл уже нарушает всеобщность хранения конфигов в gconf.

> Какие еще есть?

LDAP. Где-то проскакивало, что еще народ для какой-то реляционной БД делать бекенд. Гугл в помощь.