> а по вопросу. _Мега_ админу и так трудно, 3 таких языка + программирование + технологии + еще что-то. Может пусть он не будет учить Sendmail.cf, httpd.conf, smb.conf, .... и помнить где лежит mc.ext (я все время лезу за ним /usr/lib/mc а не в /usr/share/mc :) ) А если надо иксы поднастроить, то там для конфигов вооообще стандарт не писан. Просто посмотрите где что если найдете :)

Про что и речь! Может сначала попытаться навести порядок в существующем бардаке, чем создавать на его основе новый? Или надеетесь, что порядок сам собой явится? Хрена там, только гимору прибавится!
Вот когда всё станет красиво, насколько это возможно, в сегодняшней /etc, тогда и беритесь за модернизацию.

> IMHO, когда svu говорил про зависимости, он не это имел ввиду. ТАм разбирался скрипт в котором были зависимые переменные. И svu сказал что если они завасимы, то пусть программист сам отслеживает зависимости. Про встраивание такой фичи в реестр разговора вроде бы не было.

Ага, у меня уже появились толкователи:). А еще мной скоро детей пугать начнут - противники LR:))) Да, Вы меня поняли правильно по поводу зависимостей. LR - ОЧЕНЬ простой механизм. Только иерархия и name=value. И ВСЕ! Не более и не менее. Даже мои мечты про ChangeSet&notification - это только мечты (правда, реализованные в gconf). Так что под слово bloat эта системочка никак не подпадет. Другое дело, что такой простой и примитивный механизм нужен бывает разработчикам ТАК часто, что его унификация имеет смысл.

Мда, со вчерашнего дня тред распух...

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

>Чем он ХУЖЕ, тут уже раз 100 объяснялось.

Можно просто список, явных минусов реестра, не проблем при переходе или еще чего-нить, а я потом Вам список явных минусов текущего пожхода :) Даже ссылку дам ;)

>>>Второе: я и просил внятно мне объяснить, чем реестр лучше "плоских конфиг-файлов"?

А ты сам себе ответь, чем иерархичекая файловая система с каталогами лучше файловой системы вообще без каталогов.

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

German Ivanov.

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

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

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

Странно. А я не заметил тут ни одной ссылки на Винду...:( А зачем - тут же много объяснили: единый интерфейс для программистов и единый формат для админов (и единый способ доступа). Следующий этап - стандартизация скриптового языка:)) Шутка. Хотя, можно считать microsoft scripting host в каком-то смысле реализацией этой шутки:)

Вообще, по-идее, дистростроителям такая штука (не обязательно именно LR - возможны альтернативные подходы) должна быть выгодна - они же первые страдают от бардака в /etc - так что возможно, они и сделают что-то такое (а если сделают большие компании - и остальные никуда не денутся).

По поводу путей, как они смогут это сделать. Сначала будут внутренние патчи у редхата и пр.. Потом, когда эти патчи постепенно выпрямят, из зальют в основные деревья (configure --with-lr). Потом эта опция станет умолчательной. А потом, если будут вкусные фичи, которых нет в текущих системах конфигурирования - их начнут реально пользовать. There are ways...:)

anonymous (*) (04.06.2004 0:54:56):

> ИМХО, если будет либа, через которую можно будет работать с реестром, и если она приживется, то все, имхо, стандартизируется. В любом дистрибутиве, который с реестром, можно будет одной коммандой взять/постаить ip на сетевой карте, и не присматриватся к конкретной реализации дистрибутива. Собственно и стандарт, и дистрибутивы причешутся. Можно будет написать linuxconf ( опять он :). LR - это просто как вариант решения проблем.

Опять...

Ок, 2 вопроса.

1. Какое отношение реестр имеет к стандартизации? Почему вы хотите стандартизовать именно его? Я _ЭТО_ спрашивал.

2. Допустим, идея реестра прижилась (чего никогда, слава Богу, не случится). Уверяю Вас, в каждом дистрибутиве будут свои реестры, друг с другом несовместимые. Чем вам это поможет?

>> Точно так же, когда вы приходите в магазин и вас уверяют, что "Компьютер" и "Вындус" -- синонимы. Это хорошо? -- несомненно; меньше будешь знать -- позднее состаришься :-)

>Простите, не вижу связи между нужностью LR и этой аналогией.

Объясняю: пока что единственным аргуметном, приведенным в защиту LR как панацеи стандартизации, был: "Должно сработать, поскольку в Вындузе-то работает!"

Тогда зачем вообще заморачиваться стандартизацией? Не проще ли перейти под Вындовс и забыть все остальное как страшный сон? И не будет геммороя с дистрибутивами, и продавцы в магазинах будут вас понимать, и команду ifconfig для смены ip знать не надо будет!

Мдаа, представил конфиг exim'a с нашего почтовика в виде пар name=value размазанных по файликам. Не спасибо, такой х.ней пусть господин svu пользуется :-P

:-) Хорошо, успокоился :-)

>Это относилось к предложению сделать стандартными GUI qt и gtk. Как можно делать стандартным то, что несоблюдает стандарты.

Это наболевшее из долгого пользования DDD. Если бы его портировали с угробищного мотифа на qt или gtk, пользоваться им стало бы в разы приятнее. И Qt и Gtk приемлемо работают со стандартами. То, что они не пользуются xrdb - их выбор, и сложно с ним спорить. Qt работает не только на X, и, к тому же, ты видел доки по X Resource? Кошмар ведь! Круче тольно XGetWindowProperty :-))) Только без него не обойтись, а то буфер обмена работать не будет :-)

>Прочитай что-нибудь _кроме_ комментариев svu. Встраиваемый язык (пусть даже lisp) - очень удобно. Можешь посмотреть на примерах emacs и sawfish.

Согласен, что удобен, но ве всегда и не везде. Если сама программа меньше этого интерпретатора... :)

И всё же основной объём здравого смысла именно в этих комментариях. Как разработчик ПО я хочу просто иметь возможность сохранять и читать просиые настройки. Семантику уж как-нибудь сам прикручу, а вот сканёр - синтаксис - вещи стандартные.

Коль зашёл разговор о Qt - полезно посмортеть на QSettings. Не идеальное решение, но вполне приемлемое. Когда я его использую, мне абсольтно наплевать, куда положится этот конфиг, (если захочется узнать - в доке описано, эт так, "во избежание" (c) "понедельник начинается в субботу") - я просто говорю

c.writeEntry ( "x window pos", x() );

а потом

move( c.readNumEntry("x window pos"), ... )

и никаких

config.l, config.y, flex, blablabla для _каждого_ проекта.

Только вот если программа маленькая и не гуёвая - идём к комментариям svu :-))))), а потом в LR.

>Перечитай тред. Ответь себе на вопросы "Какие проблемы решает эта либа? Как она это делает?"

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

Что не так? Неужели не проще развивать _одну_ либу чем писать одно и то же по 100 раз? Тут хороший комментарий проскочил про Оккама...

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

полегчает.

>>>>Тогда зачем вообще заморачиваться стандартизацией? Не проще ли перейти под Вындовс

Дался тебе этот Вындос, :) имхо ты сам ничего помыслить кроме него не можешь. Вот растолкуй мне плииз чем etc размещенная на отдельном разделе винта отличается от виндового реестра ? Нет серьезно!

про стандартизацию.

> Следующий этап - стандартизация скриптового языка:)) Шутка

Это как раз не шутка, а здравый способ. Именно с этого и надо начинать. Либо мы все делаем на POSIX shell (LISP? perl? еще что-то?), либо придумываем свой стандарт -- хорошенько думаем, чего не хватает у POSIX shell и добавляем это (?). Следующий шаг -- стандарт вроде FHS , только относительно конфигов. А уж backend -- то ли это LDAP, то ли просто /etc , то ли debconf, то ли еще какой-нибудь blahconf -- дело пятое, им можно заняться когда будут выполнены первые два этапа.

> configure --with-lr

Вот к auto* вместо б&%#ского m4 вполне можно было бы прикрутить что-то вроде этого злосчастного registry...

bizanine (04.06.2004 12:43:55):

> Можно просто список, явных минусов реестра, не проблем при переходе или еще чего-нить, Я что, на магнитофон похож? :-) См. выше по треду.

mihalych (02.06.2004 18:52:43)

bsh(02.06.2004 17:20:39)

Atichrist (02.06.2004 17:15:04)

in_a (02.06.2004 17:04:35)

bsh (04.06.2004 6:34:08)

и т.п.

> Вообще, по-идее, дистростроителям такая штука (не обязательно именно LR - возможны альтернативные подходы) должна быть выгодна - они же первые страдают от бардака в /etc

Они сами этот бардак и разводят... Каждый будет делать свой реестр, стопроцентно! Не ходи к гадалке. :-)

anonymous (*) (04.06.2004 12:45:03):

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

1. Это НЕ так. То. что ты описАл, сродни системе /proc

2. ЗАЧЕМ мне СПЕЦИАЛЬНАЯ файловая система для хранения информации о настройках программ? Чем тебя не устраивает существующие?

> Вот растолкуй мне плииз чем etc размещенная на отдельном разделе винта отличается от виндового реестра ? Нет серьезно!

А ты поработай с тем и с другим. Перестанешь задавать глупые вопросы!

бей Qt'-ов

> Это наболевшее из долгого пользования DDD. Если бы его портировали с угробищного мотифа на qt или gtk,

Во первых, не с motif'-а, а lesstif'-а. Во-вторых, если б портировали с угробищного qt <здесь должен быть слишком длинный список> на motif, жить стало бы легче.

> Qt работает не только на X, и, к тому же, ты видел доки по X Resource? Кошмар ведь!

X -- это отдельная сказка... Страшная... Очень... Но вместо _стандартного_ toolkit'-а плодить еще два...

> >Прочитай что-нибудь _кроме_ комментариев svu. Встраиваемый язык (пусть даже lisp) - очень удобно. Можешь посмотреть на примерах emacs и sawfish.

> Согласен, что удобен, но ве всегда и не везде. Если сама программа меньше этого интерпретатора... :)

$ apt-cache show librep9 | grep -e '^Installed-Size:'

Installed-Size: 1336

(Да, нужно стандартизировать скриптовый язык; это не обязательно должен быть LISP)

>>>1. Это НЕ так. То. что ты описАл, сродни системе /proc

А что не так? То что при считывании неких ключей приходится юзать дополнительное апи(переходить от идеологии каталога к разбору файла) Так это имхо только минус.

>>>ЗАЧЕМ мне СПЕЦИАЛЬНАЯ файловая система для хранения информации о настройках программ?

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

bizanine (04.06.2004 12:45:37):

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

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

Это я выразил "квинтэссенцию" подобной аргументации. В данном трэде этот аргумент молчаливо подразумевается (т.е. тут я пока просто не увидел ни одного рационального аргумента)

(также svu (04.06.2004 12:51:49) адресуется)

>>>А ты поработай с тем и с другим.

Поработал с тем и другим, глупый вопрос остался. Вон даже для FAR и Total Commander плагин есть который трактует виндовый реестр именно как файловую систему.

>Во первых, не с motif'-а, а lesstif'-а. Во-вторых, если б портировали с угробищного qt <здесь должен быть слишком длинный список> на motif, жить стало бы легче.

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

А API? Это ж страшнее чем голимые X-ы! Плюс не нашли, как заставить его слать событие на изменение позиции в listbox, если курсор двигать не вниз, а вверх (с клавы), плюс много чего ещё.

Нет уж, пасиб, стоя и в гамаке - это на любителей. К тому же и выглядит так, как будто писали стоя и в гамаке...

Плюс к теме треда это никакого отношения не имеет...

>(Да, нужно стандартизировать скриптовый язык; это не обязательно должен быть LISP)

Это даже на первый взгляд _намного_ сложнее, чем создание елиного api для простых конфигов. Потому как при конфиге задача одна - хранить ключики в дереве, и всё. А вот скрипты - это ж песня, как говорил Карабас Барабас в анеке :-)

Не хочется спорить, но именно с точки зрения стандартизации и унификации, поведение Qt- и gtk-приложений возмутительно. Это хуже, чем игнорировать стандартное api реестра. :) а уж то, что их параметры нельзя на ходу менять графическим конфигуратором editres - совсем плохо.

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

> Интересно, а UNIX доживет до 19 января 2038?

Уже сейчас есть 64-х разрядные процессоры. А уж через тридцать лет о 32-х разрядах будут помнить только выжившие в ядерном конфликте. Так что никакой проблемы я здесь не вижу.

Кстати, я написал программку, которая отслеживала переход в 32-й разряд этой зимой и кидала всё в лог. По какому поводу мы с корешами неплохо выпили и закусили.

kcp

> В данном трэде этот аргумент молчаливо подразумевается

Мда. Дальше пойдет чтение мыслей на расстоянии:)

> (т.е. тут я пока просто не увидел ни одного рационального аргумента)

В самом документе есть объяснение, зачем нужен реестр. И тут это было разжевано многократно. Скажем так, вопрос в том, является ли текущее состояние /etc бардаком с Вашей эстетической точки зрения. Если нет - мне действительно Вам нечего предложить. Если да - подумайте, можно ли исправить ситуацию на корню без введения чего-либо подобного LR. Как минимум - в форме, предлагаемой PitStop - но мне почему-то кажется это решение половинчатым и обладающим теми недостатками, на которые я указал.

> Поработал с тем и другим, глупый вопрос остался.

И что ты там "наработал"? Какие впечатления от того и другого? Сикока талмудов перечитал?

> Вон даже для FAR и Total Commander плагин есть который трактует виндовый реестр именно как файловую систему.

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

svu (04.06.2004 13:36:59):

> В самом документе есть объяснение, зачем нужен реестр.

Пошли по кругу?

Извиняюсь, но мой спортивный интерес иссяк.

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

1) вместо названия файла конфига - название вложенного каталога.

2) В качестве названия параметра - название вложенного каталога

3) Файлами являются лишь значения параметра.

То-есть винда пошла чуть дальше по дереву папок etc вот и вся разница! К слову и парсить вручную такую структуру имхо проще.

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

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

ps: Нет ничего нового под луной... Так чего все так взбеленились? Страшное слово винда услышали?

>>>>И что ты там "наработал"? Какие впечатления от того и другого?

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

>>>>Сикока талмудов перечитал?

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

>Представление ещё не есть истинная форма, не так ли?

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

> но мой спортивный интерес иссяк.

Я тоже уже устал:) Напоследок ответьте все-таки плиз - Вам нынешний /etc нравится?

Продолжая эту аналогию, можно сказать, что бабушка - это дедушка у которого

1) вместо яиц - ничего.

>>>вместо яиц - ничего.

Аргументируй. Я свою точку зрения аргументировал. Возражений пока не вижу.

Перечитай тред. От иерархического хранилища пар имя=значение до полноценного прозрачного надежного и предсказуемого способа конфигурации (сравнимого с текстовым конфигом) - дистанция огромного размера.

svu (04.06.2004 13:47:49):

> Вам нынешний /etc нравится?

Странный вопрос...

Скажем так -- я не вижу проблем, описываемых Вами.

Есть проблемы со стандартизацией -- от дистра к дистру содержание /etc слегка меняется.

IMHO основной генератор проблемы -- попытки ввести ведущими производителями дистрибутивов некое подобие централизованного реестра.

2svu (*) (04.06.2004 13:47:49)
>Я тоже уже устал:) Напоследок ответьте все-таки плиз - Вам нынешний /etc нравится?
/etc - не девушка, тем более не девственница :-). Реестр для хранения всего и вся - хреНОВАЯ идея.
З.Ы. Стремление навести порядок говорит об отсутствии порядочности. (с) Ф. Ницше.

другой анонимус :-)

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

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

> Lesstif - это ж бесплатная реализация мотифа вроде...

Нет, это что-то, на него похожее.

> А про легче - это не знаю...

Точно говорю -- легче. Когда нужно быстренько собрать программу [под какой-нибудь коммерческий *NIX] , а она вдруг хочет Qt...

>>(Да, нужно стандартизировать скриптовый язык; это не обязательно должен быть LISP)

> Это даже на первый взгляд _намного_ сложнее, чем создание елиного api для простых конфигов.

Потому, что это действительно _может_ решить проблему, а не перенести ее в другое место.

Ну раз тут мы все устали, то я тоже отдохну :) По ссылкам попозже пошарюсь, ок ? :) Те вопросы я не помню, помню, что только до 7 страницы, до комментария int19h (*) (02.06.2004 21:59:52), int19h решился протестировать :) шел сплошной флейм о том нафиг нужен один большой файл, зачем там XML, о цвете синего экрана и т.д. :) Что, как мы теперь мудро понимаем, имеет мало общего с действительностью :)

> нынешний /etc нравится?

Если можно - уточните, какой /etc имеется в виду (дистрибутив). И много ли /etc-ев вы просматривали?

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

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

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

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

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

> Тред я читал, но вот пока но не понимаю фразы "полноценного прозрачного надежного и предсказуемого способа конфигурации" и не понимаю почему такой файл лежащий на унифицированной(а значит по умолчанию ущербной) файловой системе хорош

Потому, что унифицирован способ хранения, а на содержание никаких ограничений нет.

> , а на специализированной заточенной именно под него плох.

А вот кто тебе про "специализированной заточенной именно под него" сказал. Какие ваши доказательства. Ограничения на структуру и содержание - видны невооруженным глазом, а где доказательства оптимальности и "заточенности"?

dpkg-reconfigure

А как у dpkg-reconfigure всё это устроено? Вроде 10^3 пакетов в репозитории и всё нормально работает и конфигуряется с существующим /etc.

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

Ура! - это то, что осталось от "Хур-рах", а Хур, это вроде божок такой языческий был. Смешно, что христиане в бою прославляют какого-то беса. ;)

зачем ради этого городить хрен знает что?

> 1) вместо названия файла конфига - название вложенного каталога.

> 2) В качестве названия параметра - название вложенного каталога

> 3) Файлами являются лишь значения параметра.

А зачем под это все городить какой-то особый API? Почему то же самое нельзя соорудить на "обычной" (everything is file) ФС? И не надо никаких парсеров -- просто читаем файлы...

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

Не льсти себе. Обычные бла-бла из общих соображений, основанные на "всеобщей теории правильности".

bizanine: >Можно просто список, явных минусов реестра, не проблем при переходе или еще чего-нить, а я потом Вам список явных минусов текущего пожхода.

Чем текущий подход плох, все знают. Но предлагаемая альтернатива решает слишком мало проблем, чтобы на неё переходить. Кстати, там, где разделение конфига на мелкие файлы решает проблемы - это используется - modules.conf и /etc/modutils в Debian, /etc/modutils.d в ALT.

1 They don't have a common file format 2.A system administrator must know all these formats.

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

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

Different distributions may put different software configuration in different places with differente formats. A regular SuSE system administrator, for example, will be lost when asked to work in a Debian or Slackware system. Think about the most primitive example: network configuration parameters. Each distro has its own approach.

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

3. There is no way to know today what was changed in a specific configuration file. If /etc/shadow file time changes, there is no way to know if the change was related to nobody's or root's record.

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

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

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

High-level system administration GUIs (webmin, redhat-config-*, SuSE's YAST, etc) are just a dream today. They can never track successfully all changes that happens in the format of the configuration files of such a rich diversity of Open Source software (httpd.conf, smb.conf, modules.conf, fstab, etc, etc, etc). The approach of some of them is to keep the configuration ideas in a private database and regenerate the specific configuration file whenever a change happens in this database. Welcome to the inconsistency nightmare.

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

Да любой. Видел я /etc на солярке (вот, сейчас еще раз спецуально посмотрел). Видел на слаке, редхато-федоре и дебиане. Везде тот же бардак и суп из форматов. Вообще, реально бывает 2 типа /etc - один от BSD, другой от AT&T. Субъективно мне нравится второй больше, но это не важно - суп-то все равно тот же...

1)slocate postgresql.conf

2)find / -name postgresql.conf -print

ниужели 1 или 2 - 20 минут искало? %)

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

>>>>Потому, что унифицирован способ хранения, а на содержание никаких ограничений нет.

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

>>>>А вот кто тебе про "специализированной заточенной именно под него" сказал. Какие ваши доказательства.

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

>>А вот кто тебе про "специализированной заточенной именно под него"

Сам вывел :) чуть выше я сравнивал etc и виндовый реестр .