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

Ну что рыпаться-то? Вы же проигрываете эту битву участок за участком;) Наше дело правое, массовое, бабловое и индустриальное!

>Наше дело правое, массовое, бабловое и индустриальное!

звучит как быдловое, вындовое и триальное

>Да я бы не сказал, что ленивые. Парсер key = value могу накатать хоть щас!! И посмотреть, что от могут противопоставить этому xml-щики

Так в этом весь цинус, что им НИЧЕГО катать не надо #include "..." или use ... Им даже сам xml знать не обязательно "корованы пограбили за них" другие.

Кстати такой аргумент как некорректные данные в значении ключа и программа крашится, могут приводить только неисправимые быдлокодеры. Нормальная программа вместо некорректных данных будет использовать значения по-умолчанию или запросит их у юзера во время работы и исправит в конфиге на правильные. А правильная программа вообще должна запускаться в первый раз без всяких конфигов и сгенерировать конфиг сама из стандартного шаблона с комментариями и вариантами ключей.

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

А с учётом gconf/xfconf имеем ещё худший вариант. Программа прибита к демону гвоздями и без него неработоспособна. Если в вынде реестр один, то тут будет зоопарк демонов.

ЗЫЖ, я ещё не учёл быдлокодеров, которые делают часть настроек доступными только через gconfeditor. Таких, однозначно, в биореактор!!

Ничего страшного, сначала демоны расплодятся - потом догадаются объединить интерфейсы.

А насчет скрытых настроек - это вполне нормально. Ибо через GUI надо показывать только то, что нужно большинству. А поверюзерам можно дать больше возможностей.

>А с учётом gconf/xfconf имеем ещё худший вариант. Программа прибита к демону гвоздями и без него неработоспособна. Если в вынде реестр один, то тут будет зоопарк демонов.

Это смотря как написать. Никто не мешает указать в программе дефолтные значения, которые используются при отсутствии на горизонте xfconfd. Делают же так, если под боком не находится конфиг файла.

>Пофиг, лишь бы не тормозило

Пишут что xfconfd быстрее чем mcs-settings

>А насчет скрытых настроек - это вполне нормально. Ибо через GUI надо показывать только то, что нужно большинству. А поверюзерам можно дать больше возможностей.

самое интересное, что они собираются указать все возможные настройки, если не врут.

главное чтобы его с помощью vi можно было редактировать

> Тред все больше и больше напоминает спор между ленивыми программистами, которые с трудом асилили xml и боятся асиливать что-то еще и сисадминами, которые испробовали говнеца аля настройка по-мелкософтофски с галочками в самых интересных местах, дебрями ключей в реестре и полным отсутствием внятной документации на все это и им ОНО не пришлось по вкусу.

Частично согласен.

Однако, реестр и XML напрямую не связаны: реестр -- централизованное хранилище информации (этакая База Данных с самопальной архитектурой), а XML -- один из форматов передачи информации. Длительно хранить данные в XML, это то же самое, как использовать, под, скажем, сарай или гараж, железнодорожные вагоны.

Профессиональное системное программирование всегда отличалось атомарностью, а в unix-like этот принцип с рождения был возведён в абсолют.

Непонятна попытка програмастов запихнуть всё в реестр (т.е. кастрированную Базу Данных). Тем более непонятна попытка преподнести это, как нечто новое. В unix-like системах издавно существует полнофункциональная Berkeley DB (http://www.inode.ru/articles/database/2006-02-12/296), услугами которой при необходимости пользуются.

Естественно, что психологически бывшим Delphi-кодерам не привычно жить в функциональной простоте и чистоте. Понятно, что молодёжи хочется вы*нуться, чтоб заметили и оценили, старикам хочется тряхнуть седыми я*цами, чтоб ощутить самим и показать окружающим, что способны ещё на какие-нибудь свершения... Однако, ни те ни другие, как правило, не имеют никаких архитектурных обоснований, в духе Таненбаумa, для своих "маленьких революций" или больших пакостей, а, скорее, страдают "маленькими полюциями" на мифические новые веяния, сферические новые требования и туманные обещания, что когда будет реестр, то тогда "ого-го!", ибо, "как можно заметить, вся сила Windows -- в реестре, а она ... ну, вы сами знаете!". :-)

> Наше дело правое, массовое, бабловое и индустриальное!

Вот тут где-то ошибочка закралась. Что здесь лишнее "правое" или "бабловое"?

Re^4: В XFCE тоже будет реестр

> А насчет скрытых настроек - это вполне нормально. Ибо через GUI надо показывать только то, что нужно большинству. А поверюзерам можно дать больше возможностей.

Поверюзерам достаточно дать кнопку "Advanced options...". Хотя, чтобы не вводить в прострацию аутистов, придётся её скрывать, если обнаружен гном.

Re^6: В XFCE тоже будет реестр

> Ну что рыпаться-то? Вы же проигрываете эту битву участок за участком;) Наше дело правое, массовое, бабловое и индустриальное!

Да-да, миллионы мух, вас больше :)

> самое интересное, что они собираются указать все возможные настройки, если не врут.
Что помешает автору конкретной прикладухи под xfce (если такие бывают) указать не все?

> Поверюзерам достаточно дать кнопку "Advanced options...".
Нафига? Лишняя работа по поддержке этой кнопки и всего, что за ней. Потеря времени.

> Да-да, миллионы мух, вас больше :)
Горе одному,
один не воин -
каждый дюжий
ему господин,
и даже слабые,
если двое.
А если
в партию
сгрудились малые -
сдайся, враг,
замри
и ляг!
(с) В.В. Маяковский

Re^6: В XFCE тоже будет реестр

>> Поверюзерам достаточно дать кнопку "Advanced options...".

> Нафига? Лишняя работа по поддержке этой кнопки и всего, что за ней. Потеря времени.

Ах да, набросать ещё одну формочку с десятком чекбоксов ведь так сложно в библиотеке gtk... Но шерифа такие проблемы мало волнуют.

> Ах да, набросать ещё одну формочку с десятком чекбоксов ведь так сложно в библиотеке gtk...
Программист должен стремиться к уменьшению кол-ва кода;)

Re^8: В XFCE тоже будет реестр

>> Ах да, набросать ещё одну формочку с десятком чекбоксов ведь так сложно в библиотеке gtk...

> Программист должен стремиться к уменьшению кол-ва кода;)

...в чём xml и *conf совершенно не помощники.

Это да. Они про другое.

> Это да. Они про другое.

Не про программистов?

Re^10: В XFCE тоже будет реестр

>> Это да. Они про другое.

> Не про программистов?

Don't call them developers. Monkeys!

Балмер, Вы думаете, про кого пел песню "Developers"?;)

>Балмер, Вы думаете, про кого пел песню "Developers"?;) svu ***** (*) (17.09.2008 13:30:41)

Тю, а я думал Красная Шапочка "... А-а! Обезьяны, кашалоты, А-а! Крокодилы, бегемоты. И зеленый попугай..."

Люди. Поменьше фанатства. Ну реестр - значит реестр. Разработчикам видней.

Получится партия слабых, которые поубивают друг друга.

Я вообще не понимаю, почему народ настолько зациклился на XML? Неужели его парсить сильно сложнее c-style конфигов, как у bind или dhcpd? В то же время такие конфиги гораздо читабельнее и легче редактируются обычним текстовым редатором.

Если продолжить дальше - что плохого в ini-файлах, если настройки простые? Что плохого в файлах, где колонки разделяются пробелами или табами или двоеточиями? Что плохого в файлах где в каждой строке разделённые пробелом пары ключ-значение?

Парсить неудобно? Парсеров много надо? Хочется чтоб "глобально и надёжно"? Тогда всё ясно - это просто быдлокодерство. Только быдлокодеры думают о себе, а не о пользователях.

Давно бы уже написали универсальную библиотеку, которая бы парсила любой из перечисленных форматов конфигов в древовидную структуру для обработки из программы. Если ещё такую библиотеку научить сохранять дерево в любом формате - так вообще проблем никаких не будет. Формат стал слишком прост? Импорт конфига из одного формата - экспорт в другой, меняем структуру конфига.

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

Это наверно будет глобальная и надежная библиотека.

> Но боюсь это начало капца этого DE и начала пути к монструозности. Очень жалко.

Да давно уже наблюдается, сугубо субъективное наблюдение, по скорости работы/потреблению памяти был достигнут максимум, теперь идет спад. Насчет централизованного хранения настроек... хм, чем просто .config не угодил, не понятно.

Сейчас перебрался на LXDE, замечено ещё вот что:

http://hatred.homelinux.net/wiki/zhurnal:2008-08-29_17.45_lxde_hint_usr_share...

и вот как это в XFCE4:

http://hatred.homelinux.net/wiki/zhurnal:2007-11-30_01.08_vremennoe_reshenie_...

Но код у них конечно довольно внятный и читабельный.

> Балмер, Вы думаете, про кого пел песню "Developers"?;)

это вообще психоз, мозг разрывает :-D

Я вот думаю, а чего они настройки в базе данных, да хотя бы в том же MySQL (вместо MySQL подставить что хотимс) не хотят хранить (вообще касательно всего и вся, не конкретно XFCE/Gnome), один хрен, демон gconf или xfconf должен болтаться, чем демон базы данных хуже?

Видимо потому, что ручками править конфиги в SQL еще хуже чем в XML

>вот как это в XFCE4:

угу, все написали по патчу к exo. Похоже что разработчик libexo не родной остальным разрабам XFCE :) Вот на это и забили... судя по всему никаких изменений в exo на этом фронте не предвидится.

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

>Это наверно будет глобальная и надежная библиотека.

Ха-ха-ха :D Да, для таких быдлокодеров это будет то, что нужно.

Вообще XML предназначался для древовидных баз данных. Это текстовый формат, но это формат не для чтения людьми. То есть xml - это не тот текст, в котором можно хранить конфиги, редактируемые человеком.

Текстовым, по сути, он был сделан/выбран в противоположность двоичным форматам. У двоичных форматов есть свои заморочки: порядок байтов, необходимость указывать размер блока, сложность расширения формата. Из двоичных форматов наиболее близок к XML по идеологии формат IFF (к которым относятся avi, wav, современный lwo). Но из-за названных проблем двоичных форматов лучше использовать текстовый формат, на роль которого был выбран/придуман xml. Этот формат хорошо подходит для документов OpenOffice, для каких-то выгрузок, отчётов, обрабатываемых программами, но не для редактирования руками.

>Этот формат хорошо подходит для документов OpenOffice, для каких-то выгрузок, отчётов, обрабатываемых программами, но не для редактирования руками.

Не идеален, да. Однако редактировать возможно.
Инструменты есть и для ручного редактирования. А вот это, например:

# set variable identifying the chroot you work in (used in the prompt below)
if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

# set a fancy prompt (non-color, unless we know we "want" color)
case "$TERM" in
xterm-color) color_prompt=yes;;
esac

# uncomment for a colored prompt, if the terminal has the capability; turned
# off by default to not distract the user: the focus in a terminal window
# should be on the output of commands, not on the prompt
#force_colored_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

Невозможно разобрать програмно. Не в смысле чтоб прочитать... А в смысле:

c=config('~/.bashrc')
cp = c[color_prompt]
трампампам
с[color_prompt] = True
c.write()

И уже 10000 раз объясняли уж лучше 1 парсер в памяти большой, чем миллион маленьких.

Хотя все эти споры ерунда. Я как разработчик в 70% пишу конфиги в XML.
Именно потому, что обслуживаю свои програмы и с такими конфигами очень удобно работать

>Не идеален, да. Однако редактировать возможно.
>Инструменты есть и для ручного редактирования.

Да, есть можно и руками, можно палочками, можно лопатой. Вопрос в удобстве. Для настройки чего-либо руками xml очень неудобен.

>А вот это, например:
>...
>Невозможно разобрать програмно. Не в смысле чтоб прочитать... А в смысле:
>...

Во-первых - это не конфиг, а скрипт.
Во-вторых, если это невозможно разобрать программно, чем тогда занимается shell, просит у пользователя пояснить что и где написано или через libastral догадывается?

>И уже 10000 раз объясняли уж лучше 1 парсер в памяти большой, чем миллион маленьких.

Где вы миллион взяли? Общеупотребительных форматов конфигов всего штуки 4-5. Если хранить данные в xml - ничего не имею против. Если настройки - увольте, лучше использовать два парсера - один для данных, другой для конфигов. Но при этом настройка не превратится в борьбу с угловыми скобками и поиск тега десятикратной вложенности в текстовом редакторе. Конфиги должны делаться с расчётом на удобство ручного редактирования!

>Хотя все эти споры ерунда. Я как разработчик в 70% пишу конфиги в XML.
>Именно потому, что обслуживаю свои програмы и с такими конфигами очень удобно работать

Вам удобно работать с такими конфигами из программы. УДОБНО ВАМ, а не тем, кто будет вашими программами пользоваться. Поймите уже наконец, что вы пишете программы для пользователей, а не для программистов, отучайтесь от эгоистичного быдлокодерства!

> А как на счёт хранения бинарных значений? За*бешся экранировать!!

google base64

>Во-первых - это не конфиг, а скрипт.
>Во-вторых, если это невозможно разобрать программно, чем тогда занимается shell, просит у пользователя пояснить что и где написано или через libastral догадывается?

это кусок rc файла.... А уж то, что rc файл это конфиг, это никто не отрицает надеюсь?

Так вот после выполнения такого конфига я получу ряд переменных инициализированных некими значениями.

Эти два состояния эквивалентны? Я могу снова сохранить эти настройки в файл и завтра сравнить их с теми, что выдаст rc файл?
Нет. Именно под этим я и имел ввиду нечитабельность.

В 99% конфиг содержит в себе настройки положения окон, какие колонки, какую ширину в гриде имеют (порядок опять-же).
Всякие пути и прочие DSN. Руками их править сумасшествие, но ничего, пусть лучше будет, хотя INI не исправит ситуацию:

"Sets"="Sets[9,3]"
"Sets[1,1]"="_data_"
"Sets[1,2]"=dword:00000064
"Sets[1,3]"=dword:00000001
"Sets[2,1]"="_Time_"
"Sets[2,2]"=dword:00000064
"Sets[2,3]"=dword:00000002
"Sets[3,1]"="_document_"
"Sets[3,2]"=dword:00000064
"Sets[3,3]"=dword:00000003
"Sets[4,1]"="_client_id_"
"Sets[4,2]"=dword:00000064
"Sets[4,3]"=dword:00000004
"Sets[5,1]"="_company_"
"Sets[5,2]"=dword:00000064
"Sets[5,3]"=dword:00000005
"Sets[6,1]"="_Summa_"
"Sets[6,2]"=dword:00000064
"Sets[6,3]"=dword:00000006
"Sets[7,1]"="_comment_"
"Sets[7,2]"=dword:00000064
"Sets[7,3]"=dword:00000007
"Sets[8,1]"="_nom_sch_"
"Sets[8,2]"=dword:00000064
"Sets[8,3]"=dword:00000008
"Sets[9,1]"="_data_sch_"
"Sets[9,2]"=dword:00000064
"Sets[9,3]"=dword:00000009

Еще раз повторяю я лично являюсь пользователем своих программ.
В 99% я вообще не правлю XML файлы, для этого существует XSLT и прочие инструменты. Потому XML и удобен.

<sets> <set x=1 y=1 val="_data_"/> <set x=1 y=2 val="00000064" type="dword"/> ............................ </sets>

И так далее.

Работать с этим буду

c = config.open('xyz.conf') sets[1,2] = c.get("//set[@x=1 and @y=2]/@val")

причем потом я могу сказать

sets[1,2] = '123' c.write()

И конфиг поменяется. (немного утрировал, но все-же).

Приведите пример для rc конфига....

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

Хороший пример нормального конфига, обрабатываемый shell-скриптами - это /etc/rc.conf и /etc/defaults/rc.conf во FreeBSD. Там и умолчания есть в отдельном файле, и конкретные настройки, и всё читается прекрасно.

То, что вы не редактируете xml руками, не говорит о том, что редактировать руками никому не нужно, также как и о том, что редактировать руками удобно.

Я хочу посмотреть на конфиг в текстовом файле и понять всё, что мне нужно без использования специфических программ. Я хочу настраивать программу без использования специфических программ, руками в редакторе. Я ещё раз повторяю - я не хочу искать среди угловых скобок тег 10-кратной вложенности.

Re^2: В XFCE тоже будет реестр

> И уже 10000 раз объясняли уж лучше 1 парсер в памяти большой, чем миллион маленьких.

Кому объяснили? Я наблюдал только объяснение обратного.

> Хотя все эти споры ерунда. Я как разработчик в 70% пишу конфиги в XML.
> Именно потому, что обслуживаю свои програмы и с такими конфигами очень удобно работать

Да, анонимный разработчик знает, всем попячься!

Re^2: В XFCE тоже будет реестр

> В 99% конфиг содержит в себе настройки положения окон, какие колонки, какую ширину в гриде имеют (порядок опять-же).

И чем нечитабельна строка в конфиге: "wm geometry . 123x39+0+0" ? И разве какой0нибудь xml сможет сделать её более читабельной?

> В 99% я вообще не правлю XML файлы, для этого существует XSLT и прочие инструменты. Потому XML и удобен.

А ты в курсе, что XSLT -- это тьюринг-полный язык программирования, т.е. фактически для преобразования xml-я в что-то другое надо писаьт _отдельную_ программу на не самом удобном языке?

Примерчик, так сказать proof-of-concept.

Нужно найти переменную ifconfig_rl0 в файле /etc/rc.conf и заменить её значение.

grep -v 'ifconfig_rl0=' < /etc/rc.conf > /etc/rc.conf.new
echo 'ifconfig_rl0="inet 10.0.0.1"' >> /etc/rc.conf.new
mv /etc/rc.conf.new /etc.rc.conf

Это примитивный пример, что-то может не сработать, не проверял. Что-то может не срабатывать если значение одной из переменных содержит подстроку с именем другой переменной и знаком "=" за ней. Например, ошибочно может быть удалена переменная a="ifconfig_rl0=".

Если регэкспы сделать посложнее, воспользоваться sed вместо grep, или чётко ограничить для пользователя формат конфига, то всё можно довести до ума.

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

А в xml?

Re^2: В XFCE тоже будет реестр

> Примерчик, так сказать proof-of-concept.
...
> А в xml?

А в xml то же самое, только программа для замены значения одного параметра окажется гораздо более сложной, если её писать на общеупотребительных языках, либо при1дтся есть кактус и учить xslt.

>А в xml то же самое, только программа для замены значения одного параметра окажется гораздо более сложной, если её писать на общеупотребительных языках, либо при1дтся есть кактус и учить xslt.

О чём и речь. Ну и редактировать большинство xml-конфигов из текстового редактора будет тяжеловато.

>Это примитивный пример, что-то может не сработать, не проверял. Что-то может не срабатывать если значение одной из переменных содержит подстроку с именем другой переменной и знаком "=" за ней. Например, ошибочно может быть удалена переменная a="ifconfig_rl0=".

>Если регэкспы сделать посложнее, воспользоваться sed вместо grep, или чётко ограничить для пользователя формат конфига, то всё можно довести до ума.

И получим нечто вроде /.\|*[A-z]!# итак на 4 страницы......

Вот уж читабельно,обчитаешься аж.

Оно конечно не избавит от случаев с кучей ифоф.... Но едим, же этот кактус сейчас.

А насчет примера с XML, ну так я привел с XPath.

Не, ну я понимаю grep, sed, awk... Но когда они покаждому иху стартуют по 500 штук, и все из-за того, что конфиг кто-то меняет.

А завтра захочется цифровые подписи в конфиг писать, ну чтоб хакер не поменял конфиг апача незаметно. Что делать будете? А если часть конфига надо разрешить менять, а инклюда автор конфига не предусмотрел? Да много еще полезностей есть, только вам не осилить.

Раньше были люди пихающие XML куда не надо (голос, 3Д), теперь структурированное иерархическое хранилище это мол не его предназначение.... Ну, ну

Re^2: В XFCE тоже будет реестр

> А насчет примера с XML, ну так я привел с XPath.

Тем тебе программа на awk кажется хуже программы на xslt?

> Не, ну я понимаю grep, sed, awk... Но когда они покаждому иху стартуют по 500 штук, и все из-за того, что конфиг кто-то меняет.

Форк в юниксах дешёвый, так что пофиг.

> А завтра захочется цифровые подписи в конфиг писать, ну чтоб хакер не поменял конфиг апача незаметно. Что делать будете? А если часть конфига надо разрешить менять, а инклюда автор конфига не предусмотрел? Да много еще полезностей есть, только вам не осилить.

Цифровые подписи живут без проблем в соседнем файле. А остальное высосано из пальца, дабы хоть как-нибудь обосновать использование хмл.

>Тем тебе программа на awk кажется хуже программы на xslt?

Где там XSLT???

вообще смысла большого скажем rc.d запихивать в XML нет. А вот скажем координаты окон, чтоб один WM мог поднять из конфигов другого, или меню для DM. Уже смысл есть. Тот-же крон благодаря этому можно былоб редактировать из GUI не боясь потерять свои комменты... Да и по сетки CRON на 100 машнах настраивать за раз....

Тут надо четко понимать разницу между конфигом и программой кнфигурации.

Например по деклоративному конфигу можно автоматически строить диалог preferences...