Пост гнева относительно /etc/бла-бла-бла.conf

Просто юзай один дистр.

+1 к пред. посту.

А вообще таких больших разниц не замечал. Восновном различаются места храниния стартовых скриптов (SYSTEMV vs BSD).

просто нужен использовать нормальный реестр на основе любой реляционной БД. Например того же Postgres. И хранить там _вообще_все_ конфиги, а не только PIMов как в кедах.

>просто нужен использовать нормальный реестр

А еще лучше нормальную семерочку. Вообще таких проблем не будет.

> просто нужен использовать нормальный реестр на основе любой реляционной БД. Например того же Postgres. И хранить там _вообще_все_ конфиги, а не только PIMов как в кедах.

Ага, а еще можно начать какать через рот.

Что за дистры-то? В RPM based команда rpm -qc packagename покажет расположение конфигов packagename

>просто нужен использовать нормальный реестр на основе любой реляционной БД. Например того же Postgres. И хранить там _вообще_все_ конфиги, а не только PIMов как в кедах.

И ко всем значениям в разных дистрибутивах будут разные ключи.

убей сибя, позязя!
какой нахрен реестр?
какая нахрен бд?
ты в своём уме?

Еще забыл про то, что скрипты в init.d по-разному называется, да и сам init.d...
Вообще, нормально, что оно дефолтно хотя бы в /etc
Единственное, меня каждый раз kdm раздражает с конфигом в /usr/share/...
В бздях и солярах хуже помойка.

Действительно, почему бы не использовать везде один дистрибутив, в котором вы хорошо разбираетесь. Да и не замечал особой разницы в расположении и названии каких-либо важных конфигов. Правда тоже почему-то всегда раздражали /etc/rc.d и /etc/rc.c вместо православных /etc/conf.d и /etc/init.d :}

Потому что разные мэйнтейнеры разных дистрибутивов понимают (или не понимают) FHS по-разному.

В кедах там хранятся не конфиги пим, а все объекты (письма, рсс, события, етц). Ну, по-крайней мере, в пим 4.6.

И ко всем значениям в разных дистрибутивах будут разные ключи.

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

нет разным форматам конфигов, нет велосипедам, нет разным путям на жестком диске. красота!

а еще можно будет во мгновение ока сочинять запросы типа «если монитор маленький, а разрешение невысокое, и компьютер - ноутбук, то переключиться на ноутбучный режим (себя и еще несколько прог)». Сейчас для такого нужно хитроизголяться ППЦ

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

Почему бы не использовать общую библиотеку?

общее хранилище. см пост выше)

Да уйди уже со своим хранилищем

Тогда одобряю.

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

Если использовать что-то универсальное, то это почти наверняка будет мерзкий XML. И разработчику, и пользователю будет гораздо проще, если будет что-то основанное на «параметр=значение», с небольшими наворотами под нужды конкретной программы.

Да уйди уже со своим хранилищем

не только не уйду, но и на практике покажу, насколько это круто. когда-нибудь потом.

Спорить не буду, но проблем с ковырянием xml-а не испытывал.

> пользователю будет гораздо проще, если будет что-то основанное на «параметр=значение»

ага, и конфиги ты предлагаешь конечно же править ручками в текстовом редакторе?

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

а еще гуй можно генерить из схемы конфига (и текстового тоже), если структура где-то заранее четко описана

И разработчику,

разработчик в XML или БД сможет хранить сложные конфиги. На которые потом можно будет натравить ORM типа Hibernate'а, который сможет восстанавливать состояние программы напрямую из конфига, и самому даже запросы писать не придется.

>просто нужен использовать нормальный реестр на основе любой реляционной БД

Больной, вам показан эфтаназепам три раза в день, до излечения.

*.ini - рулит

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

А для сервера?

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

Но ведь он истину глаголит! GConf рулит и педалит!

>Но ведь он истину глаголит! GConf рулит и педалит!
Ага, и едет сами-знаете-куда.

>А для сервера?

А что мешает написать консольную конфигурялку? На curses или или чисто cli, `man gconftool-2`.

>Ага, и едет сами-знаете-куда.

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

>GConf рулит и педалит!

Рулит в сторону биореактора, педаля на каждую попытку свернуть?

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

>Что мешает посылать таким же образом сигнал на релоад конфига?

И кто его должен слать?

> Конфиги которые можно редактировать только через гуй - не нужны.

XML редактировать в текстовом редакторе неприятно (особенно когда конфиг на тысячу страниц), но вполне можно.

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

Типа под угрозой расстрела заставить их писать для своих конфигов какие-нибудь rw-драйвера с поддержкой унифицированных запросов, но это же невозможно.

Можно пойти другим путем, и плясать не от файлов: сделать так, чтобы специальная программа сама работала в конфигом в своем внутреннем представлении - но принимала на вход ченджсеты, которые хранятся как раз в текстовых файлах. Но это неудобно, если кто-то из _пользователей_ вдруг захочет произвести подобную операцию вручную без гуя. Это как писать sql-запросы в командной строке.

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

но таки хранить всё в XML и строить по нему соотвествующий гуй - для фанатиков текстовых конфигов самое то. Они всё еще смогут редактировать свой ненаглядный текстовый файл без использвоания посторонних прог.

Еще один неосилятор, неспособный даже прочитать документацию и ознакомиться с функционалом предоставляемым данной библиотекой?!

Ага, или HUP послать :)

> всегда раздражали /etc/rc.d и /etc/rc.c вместо православных /etc/conf.d и /etc/init.d :}
А меня раздражают init.d вместо православных /etc/rc*

>он посылают приложению, слушающему этот ключ, соответствующий сигнал, позволяющий приложению оперативно отреагировать на изменение настроек

conky вон при изменении конфа рестартится.

>XML редактировать в текстовом редакторе неприятно (особенно когда конфиг на тысячу страниц), но вполне можно.
Размер условно-стандартной страницы 1800 знаков. Умножаем на 1000, и получаем конфиг 1.8 мег, не считая юникода. Какие есть причины, по которым не нужно закопать программу с таким конфигом?
И да, формат INI придумали уже много-много лет назад. А еще и YAML есть.

>И кто его должен слать?
Кому надо пусть тот и шлет. Можно того же демона на перле написать.

> И да, формат INI придумали уже много-много лет назад. А еще и YAML есть.

в ini еще больше кода будет

Размер условно-стандартной страницы 1800 знаков. Умножаем на 1000, и получаем конфиг 1.8 мег

man гипербола && man ирония

Какие есть причины, по которым не нужно закопать программу с таким конфигом?

например, это хорошая программа, какие еще бывают вообще поводы?


а если уж хочешь прямо пример... Программа со сложным гуём, которая при выходе в точности запоминает своё состояние. (уже ДОФИГА строчек в конфиге, которые ну никак не предназначены для ручного редактирования). Хорошо бы кстате иметь такой тулкит, который бы делал это искаропки...

>в ini еще больше кода будет
Как может формат ключ = значение занимать больше кода?

а если уж хочешь прямо пример... Программа со сложным гуём, которая при выходе в точности запоминает своё состояние. (уже ДОФИГА строчек в конфиге, которые ну никак не предназначены для ручного редактирования). Хорошо бы кстате иметь такой тулкит, который бы делал это искаропки...

Каким боком это относится к конфигу? А вообще для этого хватает сериализации.

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

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

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

разработчик в XML или БД сможет хранить сложные конфиги. На которые потом можно будет натравить ORM типа Hibernate'а, который сможет восстанавливать состояние программы напрямую из конфига, и самому даже запросы писать не придется.

Опять же, БД - слишком громоздкий вариант. И ручками тяжело править. Все «редакторы реестра» и программы для редактирования XML конфигов - редкостное говно. Если уж задумал революцию, начни оттуда.

> Спорить не буду, но проблем с ковырянием xml-а не испытывал.

Да там и нет проблем, вообщем-то. Просто неудобно.

Вот в винде реестр превратился в из /etc в /var как минимум. А всё почему? Потому что дали разработчикам в руки мощный инструмент. БД - слишком мощная штука для конфигов, да.

в итоге нужно чуть-ли не поиском по всему винту отыскивать нужный

А аналога qlist в Вашем дистре нет?

$ qlist nginx|grep /etc
/etc/logrotate.d/nginx
/etc/init.d/nginx
/etc/nginx/mime.types
/etc/nginx/fastcgi_params
/etc/nginx/nginx.conf
/etc/nginx/scgi_params
/etc/nginx/uwsgi_params
/etc/nginx/fastcgi.conf

> Как может формат ключ = значение занимать больше кода?

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

Каким боком это относится к конфигу? А вообще для этого хватает сериализации.

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

>намякиваю: связанные значения и транзакции. Хранить граф в ini не так приятно, и уж точно не так удобно для ручного редактирования. Хотя бы потому что даже дерева-то не видно, но то что графа.
Намяк насчет транзакций не понят. Насчет связанных значений, собственно можно просто оставить одно.

> Иначе в текстовом редакторе - самый быстрый способ.

если не знаешь что значат поля, какие от каких зависят, какой диапазон значений итп - фигушки чо настроишь

Все «редакторы реестра» и программы для редактирования XML конфигов - редкостное говно. Если уж задумал революцию, начни оттуда.

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

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