Да просто есть ощущение, что широкое распространение "что-то-там.d" - уже незаметно и безболезненно решает ту же проблему, что LR. разве что API сишникам не предоставляет.

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

>Выже не открываете файл прямым сигналом ядру а используете fopen или еще что покруче :)

2bizanine

Дафай расскажи как послать сигнал ядру?

Типа kill -HUP kernel, а номер сигнала какой что бы файл открыть?

Прогаммисты бля, это вы будете писать LR ?

Я уже боюсь.

>>>>/etc - не девушка, тем более не девственница :-). Реестр для хранения всего и вся - хреНОВАЯ идея.

>Забавно , те кто ратуют за реестр приводят конкретные причины, а те кто против предпочитают отвлеченные понятия. И к чему бы это :) Пишите лучше прямо - не хотим от него виндой пахнет :)

>anonymous (*) (04.06.2004 14:03:08)

Как минимум одна-- необходимость модификации существующего софта.

> Если да - подумайте,

Да, да и ещё раз ДА! Надо навести порядок сначала в том, ЧТО ЕСТЬ!!! Определить стандарт на /etc, всем миром поддержать и т.д.
Кстати, бардак не так уж и велик, как многие тут рисуют.

> можно ли исправить ситуацию на корню без введения чего-либо подобного LR.

Вводить "что-либо подобное" нужно после наведения порядка в УМАХ и как следствие в /etc :-)

> Как минимум - в форме, предлагаемой PitStop

Уж этот минимум точно необходим, к тому же является переходным вариантом и полигоном для обкатки решений.

> но мне почему-то кажется это решение половинчатым

А может просто достаточным на сегодняшний день на 99% ? К тому же (см. выше) с него легко прыгнуть и дальше. Если будет нужно.

> обладающим теми недостатками, на которые я указал.

Недостатки есть во всём. И ещё неизвестно где их боьше окажется. Если смотреть на ту же винду... а ведь её не дураки выдумали, да и разработка куда централизованней!

>Вот это попа....

>Я конечно понимаю что всё надо стандартизировать, не далее как вчера искал долбанный конфиг postgreql, искал везде, где возможно. А итоге нашёл в!!!! /var/lib/pgsql/data/postgresql.conf. Какого хрена ему там делать, я не понимаю (дистрибутив RH9). Убил на эту хрень (всмысле поиск) 20 минут. НО!!!!

>Чтобы все конфиги хранить в одном XML файле, охрененно здоровом, это не куда не годится. Это же система ещё полная ж. будет. :-(((

>anonymous (*) (04.06.2004 14:07:48)

"Там нет XML!"

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

И что, это доказывает особую приспособленность для хранения конфигов?

> Именно для этого он имхо и создавался, поправьте меня если я не прав.

Продекларировать можно что угодно. "Создавался для" и "Получился пригодным для" - разные вещи.

2anonymous (*) (04.06.2004 14:03:08)
>Забавно , те кто ратуют за реестр приводят конкретные причины, а те кто против предпочитают отвлеченные понятия. И к чему бы это :) Пишите лучше прямо - не хотим от него виндой пахнет :)
Какие такие причины? Тем более конкретные? httpd.conf или fstab не по вкусу, там все так отличается, а Вы что хотели, чтобы сервис, отвечающий за файловые системы был похож на уровне настроек на вэб сервер? С головой не дружим?

Это Microsoft сует XML куда надо и не очень. Потом придумают очередной HyperML и все будут на него переводить. А вместе с решением существующих проблем /etc с введением реестра на XML появятся новые проблемы.

процедурный подход вытекает ровно из того что процессор имеет набор регистров и если я сейчас уже не практикуюсь в написании кода на асме - не значит что никто не практикуется. хреновые привычки так просто не выковырнешь из корки и подкорки. или вы предлагаете менять стиль программирования каждый раз когда intel & co будут выпускать новый революционный процессор? :))

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

>1)slocate postgresql.conf >2)find / -name postgresql.conf -print

Еслиб я знал как этот файл завётся, я бы нашёл его таким образом, но меня попросили знакомые прийти им настроить postgresql на машине имеется токо локалка и нет выхода в инет, то есть не названия не где нужно искать я не знал, параметры которые нужно было выставить были прописаны на листочке который дали при продаже ПО, вот только забыли написать где искать этот конфигурационный файл. Сам я не работал с postgres, поэтому по ошибки искал файл с именем postgressql.conf (c лищней s). :-(( Повезло что ещё нашёл, так как просто решил заглянуть где там у него базы лежат, но базы оказались там где нужно, ну и тогда конфиг и нашёл.

> Широко юзаю и то и другое.

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

> Нисикоко. Чего там читать то?

А-а! А что, на каждую ветвь и параметр в реестре уже встроеный хелп есть?

> Если знаешь прогу которая юзает этот конфиг

А если не знаю? То что?

> (ветку реестра) то обычно все понятно.

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

> Если не знаешь, никакой талмуд не поможет.

Очень удобно! И нах мне это в linux?

> Ага. А бинарный формат etc лежащий на уровне файловой системы это как? Ты же работаешь с фронтэндом, не поверишь твой комп так вообще о файлах даже и не догадывается он 011101010 с 0101010110 складывает и вычитает.

Давай ещё музыку с сидюков попомним! Ага, после Рида-Соломона и 8-14, а ведь слушаем!

>>>А зачем под это все городить какой-то особый API?

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

Да и файлы это имхо не лучший метод хранения параметров. Рассмотрим ту модель что приводил выше.

Например зачем создавать файл для хранения числа "1" Можно представить его внутри как ту же папку или вовсе аттрибут самого параметра. А юзеру выдавать как полноценный параметр ничем не отличимый от соседнего.

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

или зачем вообще писать параметр "0"? Можно вообще его не писать, и принять что отсутствие значения и равно 0. Так и размер оптимизируется и скорость обращения.

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

Специализированная файловая система выгоднее унифицированной.Имхо это совершенно очевидно. Только боязнь перемен и привычка таскать за собой устаревший багаж и держит etc на плаву до сих пор.

Чем мне нравятся плоские файлы для хранения настроек? Задал я себе этот вопрос и начал на него отвечать:

1. Они самодокументированы.
2. Если они не самодокументированы я читаю man имя_конф_файла и узнаю много интересного.
2. Они легко жмутся и хранятся в архивах.
3. Мне для работы с ними ничего кроме текстового редактора не требуется.
4. Их легко распечатать на бумаге.
5. Из них легко выделить нужную информацию (sed,grep,awk).
7. Они не ограничивают разработчика схемой key = value которая не может быть панацеей конфигов.
8. Они более эффективно используют дисковое пространство по сравнению с множеством ключей реестра в виде файлов.
9. Исходя из П.8 время доступа к одному файлу содержащему 1000 ключей будет намного меньше чем скорость доступа к 1000 ключам в виде файлов.
10. Легко контролировать их целостность и изменения (MD5).
11. Они хорошо вписываются в политику безопасности (я не хочу чтобы пользовательская программа записывала данные в системный раздел)

Отсюда вывод: Если программа А хочет изменять файл программы Б - пусть она попросит парсер программы А - он умеет это делать. Никто не заставляет программиста писать парсер для своей программы с нуля. Бери готовый и пользуйся - тот же ccl к примеру для key = value. А в /etc/ не бардак, а рабочий беспорядок.

О! Несмотря на усталость - считаю своим долгом ответить. Чуть ли не первый за 1000 постов детальный разбор косточек того документа. Респект!

> Даже если 90% софта перевести на предложенный формат, остальные 10 всё равно кому-то придётся конфигурировать. Есть сомнения, что 100% софта перевести на единый формат не удастся?

Сомнений нет ни на секунду. Даже если только 50% (или 20%) софта будет использовать реестр - это будет софт (по законам 80-20), который достаточен для 80% админов (понятное дело, первым делом начнут патчить самай популярный софт). Скажите, велик ли набор софта, с которым приходится иметь дело среднему админу не слишком большой конторы? По моему знакомству с админами, список тех названий, которые они употребляли, уложится в пару тройку-десятков - это даже касается админов ISP. Это совершенно неподъемный труд - перевести их конфигурационный код на LR? Если код написан модульно - это совсем не сложно. Да, будет непереведенный lecagy soft - и будут админы, которым придется страдать. Их жаль.

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

Это правда. Поэтому кроме собственно библиотеки нужно соглашение по ее использованию - т.е. мера организационная. Но в случае с реестром немножечко проще, чем с /etc - нет исторических привязок, нет кандалов под названием "люди привыкли, что этот файлик лежит тут" (при этом у разных дистростроителей разные взгляды на то, где он должен лежать). А вообще - при том, что постепенно структура /etc стандартизируется в дистрибутивах (по крайней мере у rpm-based) - я думаю, и тут процесс может сойтись (а возможно, при правильном подходе, раскладка будет стандартизирована изначально - тут ведь вопрос, кто и как будет вводить стандарт).

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

Извините, не очень понял вопрос. Проверка автоматическая, программная - или проверка админом "на глаз"? Для первой - без разницы. Для второй - да, админу либо придется шариться по файлам, либо почитать XML. Либо просто взять специально заточенную морду... По поводу проверки времени модификации кучи файлов - FAM освободит Вас от такой необходимости (опять же, при правильном API библиотеки - разработчику будет не очень важно, есть там FAM или нет).

> На самом деле редко встречаются файлы со сложным синтаксисом. Синтаксис обычно хоть и различен, но прост (в сложных случаях это обычно язык программирования, и значит, не ложится в рамки key=value).

Так, про скрипты мы не будем говорить - я их тоже люблю:) А name=value синтакс обычно прост, это правда. Только дальше народ начинает разбивать это дело на секции, иерархию вводят - и тут начинается бардак "кто во что горазд". Так почему бы не иметь в системе THE configuration file parser - который используется в большинстве случаев.

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

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

8 причин по которым я не буду использовать LR

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

Это потому как вы игнорируете аргументы противоположной стороны :)

OK ! Приведу несколько причин по оторым я как разработчик НЕ БУДУ
использоваь реестр (благо как раз дописываю сейчас конфигуряльную часть текущего проекта - есть куда проецировать) .... аргументы конечно все же 
субъективные 

1) Я не хочу прикручивать лишнюю библиотеку и таскать код её обслуживающий с собой (и так уже монстр)
ss@XP1700:~/FreeCFD$ ldd FreeCFD-0.135Dev
        libpthread.so.0 => /lib/libpthread.so.0 (0x4002a000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4007c000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40143000)
        libFOX-1.0.so.0 => /usr/local/lib/libFOX-1.0.so.0 (0x40151000)
        libpng.so.3 => /usr/lib/libpng.so.3 (0x403de000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x40408000)
        libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40425000)
        libz.so.1 => /usr/lib/libz.so.1 (0x40467000)
        libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x40474000)
        libGL.so.1 => /usr/lib/libGL.so.1 (0x40482000)
        libGLU.so.1 => /usr/lib/libGLU.so.1 (0x4067c000)
        libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40722000)
        libm.so.6 => /lib/libm.so.6 (0x407d3000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x407f7000)
        libc.so.6 => /lib/libc.so.6 (0x407ff000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libdl.so.2 => /lib/libdl.so.2 (0x40935000)
2) Не желаю изучатать еще один интерфейс
3) Сложность доступа к ЛОКАЛЬНЫМ настройкам (настроек может быть несколько даже для одного юзера, в идеале юзеровские  настройки вообще привязаны к конкретному проекту)
4) Невозможность задания ничего более сложного чем key=value разложенных по веткам (ImHO это самый жирный минус - если нужно будет чего нибудь "этакое" обязательно придется иметь дополнительную сущность)
5) Не желаю чтоб кто-то мог бы лазать по моим настройкам без надобности (и сам не желаю случайно залезть в чужие) - подход All-in-One это провоцирует
6) Невозможность _простого_ экспорта/импорта настроек
7) Сложные дополнительные интерфейсы для изменения настроек 
8) Непереносимость в другие платформы где нет LR ;)


Вот что собственно сходу пришло в голову при блиц-оценке возможности
прикрутки LR к вполне конкретному поделию 

Думаю что при прикрутке всплыло что нибудь еще ...


PS: В вышеупомянутом FOX-е также имеется аналог реестра 
и он так же послан лесом (см п 4) 

>>>И что, это доказывает особую приспособленность для хранения конфигов?

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

>>>а Вы что хотели, чтобы сервис, отвечающий за файловые системы был похож на уровне настроек на вэб сервер?

F вас не пугает что настройки и того и другого вы храните в _файлах_. Ведь это одни и теже файлы, даже оба текстовые!!! "С головой не дружим?"(c) :)

Ну зачем же так зло? Ну перепутал человек syscall с signal в запарке. В конце концов - на "s" начинается, на "l" кончается, 5-я буква "а":)

есть 1024 :-)

"Там нет XML!" (TM)

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

1. Кем предназначен?

2. Как нехранение в реестре MP3 доказывает пригодность реестра для хранения конфигов?

>А я вот скажу, что меня от реестра воротит. И что?

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

>>>>А-а! А что, на каждую ветвь и параметр в реестре уже встроеный хелп есть?

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

>> Если знаешь прогу которая юзает этот конфиг >А если не знаю? То что?

То какое вам дело до ее настроек???? Имхо логично.

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

А что по веткам (ака каталогам) не прогуляться и названия не посмотреть?

>Очень удобно! И нах мне это в linux?

А нах тебе в линукс конфиги прог о которых ты ничего никогда не слышал?

>авай ещё музыку с сидюков попомним! Ага, после Рида-Соломона и 8-14, а ведь слушаем!

Кстати классный пример :) Я до него не додумался. Ну и как, напрягает тебя лично Рид с Соломоном?

А как с этим реестром использовать RSBAC или _____ chrooting?________________________________________ __________________________________________________ Вместо гибкого, разделяемого (изолируемого) доступ когда отдельные конфиги могут храниться скажем в__ зашифрованном виде и расшифровываться по мере необходимости А если под некоторые конфиги выделен отдельный ОСОБО защищенный раздел винчестера?

Ну не дурак ли ты? Что такое chrooted environment - ни ухом, ни рылом, да?

>Кем предназначен? Как нехранение в реестре MP3 доказывает пригодность реестра для хранения конфигов?

Ты бы это, то исходное сообщение висящее в шапке трейда прочитал что-ли.. Ну то которое мы сейчас обсуждаем :) Или ты про MS реестр, так почитай что у них по этому поводу пишется MSDN например...

> Например имея API в качестве фронтэнда, кододописатели могут свободно менять внутреннее содержимое

open, read, write, close -- вот Вам и front-end. А что за нами стоит, ведает только VFS, вот пусть ее курочат :)

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

Все нормальные ФС так и делают, только каждая по-разному (XFS хранит мелкие файлы/директории непосредственно в inode, у ReiserFS вообще есть tail-merging, NTFS хранит мелкие файлы непосредственно в MFT).

> Можно индексировать эту спец-файловую систему так, чтобы увеличить скорость обращения,

Опять таки, ФС общего назначения основаны, как правило, на B[+]-trees, зачем там еще одна индексация?

устал, прошу прощения :) не сигналом, а системным вызовом :)

Re:

А что есть "истинная форма" для информации на моем HDD?

Очень интересно :-)

> >Кем предназначен? Как нехранение в реестре MP3 доказывает пригодность реестра для хранения конфигов?

> Ты бы это, то исходное сообщение висящее в шапке трейда прочитал что-ли.. Ну то которое мы сейчас обсуждаем :) Или ты про MS реестр, так почитай что у них по этому поводу пишется MSDN например...

Т.е ответить тебе нечего. Прелестно.

Re:

chroot?

не прошло и трех лет...

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

> Это правда. Поэтому кроме собственно библиотеки нужно соглашение по ее использованию - т.е. мера организационная.

Я Вам про это торочу с самого начала этого гм... обсуждения. Разруха не в /etc, разруха -- в головах.

>>>Это потому как вы игнорируете аргументы противоположной стороны :)

Да ничего подобного,:) отвечаю по мере сил. Поехали по пунктам:

>>>>1) Я не хочу прикручивать лишнюю библиотеку и таскать код её обслуживающий с собой

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

>>>2) Не желаю изучатать еще один интерфейс

Думаю на первое время создадут какой либо врапер etc->LR. поэтому можно будет работать и старым образом.

>>>3) Сложность доступа к ЛОКАЛЬНЫМ настройкам (настроек может быть

А в чем сложность?

>>>4) Невозможность задания ничего более сложного чем key=value разложенных по веткам

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

>>>>5) Не желаю чтоб кто-то мог бы лазать по моим настройкам без надобности

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

>>>>6) Невозможность _простого_ экспорта/импорта настроек

А в чем сложность?

>>>>7) Сложные дополнительные интерфейсы для изменения настроек

Тут да. Но если прога ориентирована на непрофи, этого не избежать.

>>>>8) Непереносимость в другие платформы где нет LR ;)

Время пройдет все и решится.

Нет, батенька, синдром красноглазия не скроешь.

Чел путает syscall и signal, да это мелочи, зато он будет часами

доказывать, что LR - это НАШЕ ВСЕ.

Честно сказать я боюсь, это только в ляпиксе я видел убитые в хлам

фс и кернел паник от юзерленд программ, теперь новые грабли - LR.

>>>.е ответить тебе нечего. Прелестно.

А что можно ответить на вопрос о том, кто предназначил конфигурационные файлы для конфигурирования софта? Тебе фамилию назвать? :)

<offtopic>
сегодня с утра я понял как заблуждается примерно половина тут присутствующих.
тяжелое похмелье и просьба приятеля помочь (кто-то ему сервер подломал) оказались последней каплей. просмотр километровых логов и поиски закладок показали что конфиги должны быть в предсказуемых местах. точнее - в более предсказуемых чем они есть сейчас. и формат у них должен быть один. .vimrc и .emacs путь держат свои настройки в чем угодно, а стартовые скрипты в системе могли бы и поменьше кода содержать... иначе вместо оценки параметров стартующего сервиса приходится еще и отладкой заниматься.
и вообще - винда рулит. непадецки. все остальное рулит. но как-то не так... скромнее :))
</offtopic>

> Это правда. Поэтому кроме собственно библиотеки нужно соглашение по ее использованию - т.е. мера организационная. >>>Я Вам про это торочу с самого начала этого гм... обсуждения. Разруха не в /etc, разруха -- в головах.

Дык головы и ставятся на свое место централизованным апи. Им просто выхода не остается.

> They don't have a common file format.

И что?

> Their localization in the filesystem may be different from Linux distribution to distribution.

Даенам - погремушки.

> When two different softwares want to integrate themselves, it is programatically very hard to read, understand and correctly change its partner's configuration file.

LR Этого не решил. Берем пример виндовой инсталляции tomcat. Читаем что там написано про параметерс и видис что все они скинуты. Вывод - парсить ключи тоже придеться. Поменяли шило на мыло - есть стандартный парсер формата, который не нужнет, потому как являеться структурой а пропарсить надо информацию. Берем /etc/hosts и рисуем в XML. Где трудоемкость выше - создать /DOM/SAX/Digest или прочитать из файлика?

> A system administrator must know all these formats.

ЗАнимательная эта кнопка F3 - начать поиск по виндовому реестру. Нука сколько человек из виндовых администраторов назовут Registry Keys которые юзает проинсталлированный софт? Спорим в /etc/ настройку локали найти быстрее чем в виндовом реестре?

> There is no way to know today what was changed in a specific configuration file.

А еще неизветсна скорость набора на клавиатуре изменившего. И что?

>A software developer must waste a lot of time to write the plumbing code for configuration file parsing etc.

А SAX reader мне тот мудила писать будет который написал LR? Что ? Не будет? Так какая разница писать custom parser или custom sax reader?

> 5 ..Welcome to the inconsistency nightmare.

Дорогой видимо не вкуривает что нету никакой разницы измениться формат httpd.conf или сложное значение простого ключа или его местоположение. Велкам ту тот же самый nightmare.

> A regular SuSE system administrator, for example, will be lost when asked to work in a Debian or Slackware system.

А что в different paths, с different key и different values не могут? Де такую траву берут?

Вывод - чудила написал то что "он чувствует правильно" суперархитектуру, даже не задумавшись над задачами которые надо решать. Это изложение того как его решает LR. Вывод решает криво.

> Разруха не в /etc, разруха -- в головах.

Адназначна. Поэтому надо насильственно вводить дисциплиночку. Каленым железом:)))

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

Не крутись, как уж на сковородке :) Вопрос был про реестр. Кто тебе сказал, что хранение ключей в реестре есть лучший (ну хотя бы удобный) способ для конфигурирования софта?

2anonymous (*) (04.06.2004 14:40:56)
>F вас не пугает что настройки и того и другого вы храните в _файлах_. Ведь это одни и теже файлы, даже оба текстовые!!! "С головой не дружим?"(c) :)
О, ужас, вырываю на груди все волосы :-) Ведь для редактирования ФАЙЛОВ нужен редактор!!! И на... зачем добавлять еще одну сущность для редактирования, и, если рассматривать фстаб, добавлять в файловую систему еще несколько файлов? про хттпд.конф я вообще молчу :-).

> Сомнений нет ни на секунду. Даже если только 50% (или 20%) софта будет использовать реестр - это будет софт (по законам 80-20), который достаточен для 80% админов (понятное дело, первым делом начнут патчить самай популярный софт). Скажите, велик ли набор софта, с которым приходится иметь дело среднему админу не слишком большой конторы? По моему знакомству с админами, список тех названий, которые они употребляли, уложится в пару тройку-десятков - это даже касается админов ISP. Это совершенно неподъемный труд - перевести их конфигурационный код на LR?

Да как сказать. Многие из тех трёх десятков софтин входят как раз в те самые 10%. Про сендмейл уже говорили, хотя на нём свет клином не сошёлся. Тот же конфиг iptables очень сложно разложить на key-values. В простом конфиге сквида многие опции требуют жёсткого взаимного расположения. Samba позволяет подстановки вида include /etc/samba/%m.conf. И многие админы этим активно пользуются.

> Извините, не очень понял вопрос. Проверка автоматическая, программная - или проверка админом "на глаз"? Для первой - без разницы.

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

> Так, про скрипты мы не будем говорить - я их тоже люблю:) А name=value синтакс обычно прост, это правда. Только дальше народ начинает разбивать это дело на секции, иерархию вводят - и тут начинается бардак "кто во что горазд". Так почему бы не иметь в системе THE configuration file parser - который используется в большинстве случаев.

Это можно свести к ситуации с форматом почтовых ящиков. Есть mbox, есть maildir, каждый хорош по своему. Но api нет. Есть общий формат. И такой подход мне нравится больше чем реестр - пусть разработчик выбирает один из де-факто стандартов конфигов. Если не достаточно - welcome в 10% софта, который не поддаётся автоматизации конфигурирования.

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

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

Re:

:-/

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

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

> повторю еще раз: часть инициализации вы вынесли из программы в скрипт. и все. количество (общее) кода от этого не сильно изменится

Блин :-/. Вы на чем программу пишете, дайте угадаю? На C? Без встроенного интерпретатора и отсутствия самомодификации кода? Ну и как _пользователь_ сможет выставить некоторое конфигурационное свойство только для некоторой комбинации режимов функционирования? Отвечаю: только так, как _вы_ предложили с самого начала:

gui_font = bla-bla

nongui_font = blo-blo

Или, если угодно, так:

font = ... gui_font= ...

с соответствующим свитчом в программе и перекрыванием более специфичных настроек менее специфичными.

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

FreeCFD --- это гидродинамика?

kcp

>>>Не крутись, как уж на сковородке :) Вопрос был про реестр.

А я не кручусь, :) Что спроисл то и получил.

>>>Кто тебе сказал, что хранение ключей в реестре есть лучший (ну хотя бы удобный) способ для конфигурирования софта?

Тебе повторить еще раз все то, что я только что писал о достоинствах специализированной файловой системы? Реестр создавался для хранения конфигурационной информации и оптимизируется именно для ее хранения, так ничего другое в нем не хранится, и если ты хочешь запихивать туда что-то свое то велком, но никто не гарантирует тебе удобства. Имхо это совершенно очевидно? я не прав?

А если мне нужно часть программ запускать со съемного носителя, чтобы они ничего в системе из настроек не хранили?

Запустити напримем MSIE со съемного носителя, а вот Mozillу- пожалуйста, (не говоря про Lynx) - делаем ссылочку с домашней директории пользователя, с нужных конфигов и т.д.

Re:

> процедурный подход вытекает ровно из того что процессор имеет набор регистров и если я сейчас уже не практикуюсь в написании кода на асме - не значит что никто не практикуется. хреновые привычки так просто не выковырнешь из корки и подкорки. или вы предлагаете менять стиль программирования каждый раз когда intel & co будут выпускать новый революционный процессор? :))

There should be other way, bro. Не думайте о регистрах. Вообще. Все равно ничего сколько-нибудь похожего на правду вы про них не придумаете.

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

> если бы увидел первый раз комп с С с классами - думал бы скорее всего по другому, но первый раз комп был с бейсиком и асмом :*)

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

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

>FreeCFD --- это гидродинамика?

Угу ... Попробуйте-как в терминах LR описать ГУ для 3D задачи