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

> Никто никогда из этого правила не делал вывода, что 80% не нужны.

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

в который раз,

s/бардак/разнообразие/

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

Задача одна - хранение конфигурации. Соотв. библиотека должна быть одна. Тривиальна она или нет - решайте сами, для меня этот вопрос не интересен. Но то, что мелкософт, эппл и пр. вводят единую систему конфигурирования, единую БД конфигурации (забудем о недостатках конкретных реализаций, говорим о концепции как таковой) - должно натолкнуть Вас на размышления...

> s/бардак/разнообразие/

s/разнообразие/бардак/

И так до бесконечности. Не договоримся.

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

> Вы издеваетесь? Сколько утилиток надо для менеджения всех форматов в /etc? Посмотрите на несчастных людей, делавших linuxconf (почивший), webadmin и пр. Им приходится использовать отдельный парсер на каждый файл в /etc. И следить за тем, не поменял ли автор формат (например, от первого апача ко второму).

Проблемы костылеписателей меня не волнуют.

> Я доменом считаю конфигурацию. Это один домен. И DSL в данном случае - параметры командной строки gconftool-2.

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

Вот sendmail.cf, уже упоминавшийся в этой теме, -- это действительно специфичный для задачи формат конфига. Замапить его в реестроподобный формат -- отдельная нетривиальная задача.

> Проблемы костылеписателей меня не волнуют.

Это были Ваши слова, не мои. Вы сами сказали, что в /etc лезть не надо, есть утилиты. А теперь оскорбляете авторов этих утилит. Или Вы хотите отдельную утилиту для каждого файла в /etc? Со своими параметрами командной строки, своим UI, ... Нафик. Бардак. Мегабардак.

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

Все остальное к ним сводится без проблем, при наличии иерархии. Во всяком случае, пока мы говорим о конфигурации (а не о полноценной реляционной БД или геоинформационной системе)

> Замапить его в реестроподобный формат -- отдельная нетривиальная задача.

sendmail.cf - ночной кошмар админа. Выкидыш в славном мире конфигурационных файлов. Посмотрите на файлы конфигурации более адекватных в конфигурировании майлеров. Они прекрасно укладываются в дерево.

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

> Задача одна - хранение конфигурации. Соотв. библиотека должна быть одна.

Может и язык программирования один оставить? Всё ведь можно написать на C :)

Весь вопрос исключительно в удобстве. Что удобно использовать в "нестандартных" задачах -- я уже показывал.

> Но то, что мелкософт, эппл и пр. вводят единую систему конфигурирования, единую БД конфигурации (забудем о недостатках конкретных реализаций, говорим о концепции как таковой) - должно натолкнуть Вас на размышления...

Уж не знаю, как в эппл, но ходят слухи, что microsoft _рекомендует_ хранить конфиги не в реестре, а в xml-ках.

> Может и язык программирования один оставить?

Как платформообразующий - да. В унихе это С. Соотв. все системные API выражаются в терминах С. Но это совсем другая история.

> Что удобно использовать в "нестандартных" задачах -- я уже показывал.

Я не нашел в Ваших задачах ничего нестандартного, не укладывающегося так или иначе в gconf.

> ходят слухи, что microsoft _рекомендует_ хранить конфиги не в реестре, а в xml-ках.

Где об этом почитать? Радио ОБС меня как-то не очень убеждает.

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

> Или Вы хотите отдельную утилиту для каждого файла в /etc? Со своими параметрами командной строки, своим UI, ...

Да. Иначе получится уродец, который вроде бы умеет всё, но в то же время не учитывает специфики программы, сваливая все параметры в одну кучу (http://linux.softpedia.com/screenshots/GConf_1.png). Вместо утилиты конфигурации, учитывающей специфику программы(http://tklor.googlecode.com/files/tkLOR-screnshot-4.png). В принципе, мог дать и скриншот kcontrol-а, но решил соригинальничать :)

> Нафик. Бардак. Мегабардак.

Вас это вводит в фрустрацию?

> Все остальное к ним сводится без проблем, при наличии иерархии. Во всяком случае, пока мы говорим о конфигурации (а не о полноценной реляционной БД или геоинформационной системе)

Где кончается конфигурация и начинается "полноценная реляционная БД или геоинформационная система"? Грубо говоря, хранение в конфигах скриптов под какую категорию попадает?

> sendmail.cf - ночной кошмар админа. Выкидыш в славном мире конфигурационных файлов.

Это как раз специфичный для задачи язык програмирования. Тьюринг-полный, кстати. И его удобство или не удобство -- не меньший холивар, чем K vs G.

> Посмотрите на файлы конфигурации более адекватных в конфигурировании майлеров. Они прекрасно укладываются в дерево.

Да, урезав функциональность, мы получим некоторые удобства.

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

>> Что удобно использовать в "нестандартных" задачах -- я уже показывал.

> Я не нашел в Ваших задачах ничего нестандартного, не укладывающегося так или иначе в gconf.

А мне надо не "так или иначе" притянутый к gconf формат, а "удобный в конкретной задаче". Структура данных явлвется неотъемлимой частью алгоритма(да, меня укусил Вирт).

>> ходят слухи, что microsoft _рекомендует_ хранить конфиги не в реестре, а в xml-ках.

> Где об этом почитать? Радио ОБС меня как-то не очень убеждает.

Радио ЛОР об этом вещает. Я честно пытался найти ссылку, но в основном это примеры на technet, так что вряд ли это можно считать официальной рекомендацией.

> Вас это вводит в фрустрацию?

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

> Грубо говоря, хранение в конфигах скриптов под какую категорию попадает?

Скриптам не место в конфиге. Максимум - ссылка на файл со скриптом. Вы пытаетесь под "нестардартные случаи" вписать случаи откровенного бардака (причем в голове разработчиков).

> Тьюринг-полный, кстати

Потому и выкидыш. Хранилищу конфигурации не нужен такой язык. Конфигурация - это только конфигурация.

> Да, урезав функциональность, мы получим некоторые удобства.

А расширив конфигурацию - получаем bloatware. И что?

Ланн, предлагаю закругляться. Вряд ли договоримся. Слишком различны наши предпосылки.

> Структура данных явлвется неотъемлимой частью алгоритма(да, меня укусил Вирт).

+1024. Иерархия позволяет создавать любую структуру данных.

>>Ланн, предлагаю закругляться.

Я вообще не понял о чём вы спорите =)

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

> Это делает невозможным централизованное администрирование.

Конфиг-файлы можно подменять централизованно. Перезапуск демонов - тоже. Вопрос только в том, как это реализовать. Да, костыль yp -- это деталь реализации.

> Это создает совершенно ненужную нагрузку на администраторов (которым приходится запоминать кучу ненужной инфы о том, что чем и как менеджить).

Если конфиг не отражает предметной области, то его действительно сложно запомнить. Лично мне всегда хватало моей (программистской) интуиции для редактирования любого файла в /etc, будь то конфиг dhcp3 или ejabberd.

>> Грубо говоря, хранение в конфигах скриптов под какую категорию попадает?

> Скриптам не место в конфиге. Максимум - ссылка на файл со скриптом. Вы пытаетесь под "нестардартные случаи" вписать случаи откровенного бардака (причем в голове разработчиков).

Макросы в ворде, привязанные к комбинациям клавиш -- это в чьей голове бардак?

>> Тьюринг-полный, кстати

> Потому и выкидыш. Хранилищу конфигурации не нужен такой язык. Конфигурация - это только конфигурация.

Хранилищу - не нужен, мейлеру -- нужен. А мейлер важнее.

> Ланн, предлагаю закругляться. Вряд ли договоримся. Слишком различны наши предпосылки.

Ну ладно, отвечу на все сообщения и закруглюсь.

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

>>>Ланн, предлагаю закругляться.

> Я вообще не понял о чём вы спорите =)

О том, чем плох gconf :)

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

> +1024. Иерархия позволяет создавать любую структуру данных.

Как мне сохранить тензор в дерево в читабельном виде?

Кстати а как мониторить изменения в конфигах? Без централизованного управления. Это что-бы изменения вступили в силу нужно перегружать прогу чтоль? А gconf это позволяет реализовать простым способом.

> Кстати а как мониторить изменения в конфигах? Без централизованного управления.

man inotofy

> Это что-бы изменения вступили в силу нужно перегружать прогу чтоль?

Перегружать конфиги. См. как сделано, например /etc/init.d/squid reload.

> А gconf это позволяет реализовать простым способом.

Если вся картошка шарообразна, её можно просто и эффективно чистить автоматически. Проблема только в том, что не вся картошка шарообразна.

Ага. Потвоей логике получается, что для чистки картошик и, например, морковки нужен отдельный нож?

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

> Ага. Потвоей логике получается, что для чистки картошик и, например, морковки нужен отдельный нож?

Да :) Картофель чистить _удобнее_ вот этим: http://www.irita-centr.kiev.ua/TI/8215038.jpg

Изврат. Я его всегда топором чистил.

Это универсальный нож для чистки =) Я таким не только картошку чищу :-D

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

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

> Это универсальный нож для чистки =) Я таким не только картошку чищу :-D

Морковь им чистить всё-таки неудобно :)

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

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

Если настройки общие, то они лежат в одном файле и этот файл не может иметь одновременно более одного формата. В чём проблема?

> Изврат. Я его всегда топором чистил.

Белки едят картофель? 8-)

Я не про формат а про перегрузку конфигов =) Если даже они лежат в одно файле, то при изменении значения они должны узнать об изменениях. Не прикручивать же к каждой проге свой мониторинг изменения конфига =)

> Не прикручивать же к каждой проге свой мониторинг изменения конфига =)

А почему бы и не да? В любом случае возможность обновления конфига "на лету" должна быть _явно_ предусмотрена в программе.

Народ, завязывайте. Либо gaa явно шлангует и издевается, либо он никогда не писал и не администрировал ничего больше "tkLOR APP_VERSION Windows NT 5.1 intel". В обоих случаях любая аргументация будет как об стенку горох (картошка, морковка - по выбору).

Орехи нынче дороги.

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

> Народ, завязывайте. Либо gaa явно шлангует и издевается,

Я отвечаю в тему топика. При чём тут шлангование?

> либо он никогда не писал и не администрировал ничего больше "tkLOR APP_VERSION Windows NT 5.1 intel".

Увы, это единственный мой опенсорсный проект на данный момент. А про ненаблюдаемую проприетарщину, которую я за еду клепаю на работе, информация будет всё равно непроверяема. Кстати, по иронии судьбы, как раз сейчас ковыряю, что за велосипед, связанный с сохранением конфигов, написали мои коллеги :)

> В обоих случаях любая аргументация будет как об стенку горох (картошка, морковка - по выбору).

Ну почему же? Я не со всем соглашаюсь, но всё через сознание пропускаю.

GConf ничем не плох просто потому, что это конфиг гнома, а не реестр. Если бы всё было так плохо, как у оп-куна с головой, то GConf был бы плох.

> При чём тут шлангование?

При большом наборе совершенно несвязанных с темой аналогий и ассоциаций. Некорректность которых я утомился доказывать.

>Я отвечаю в тему топика. При чём тут шлангование?

не шлангуешь? Ну тогда ты реально тупой

да, это оскорбление.

администрации ЛОРа: можете применять санкции