Что придёт на смену xorg.conf?

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

>Это означает только то, что один и тот же конфиг в разное время может быть валидным или невалидным.

И это говорит упертый сторонник статической типизации.

> Ниасилил, зачем это всё. Или ты тоже хочешь сказать, что в общем случае для валидации придется писать программу?

Для валидации программу писать придётся абсолютно в любом случае. Для типичных случаев - декларативную.

"типичных случаев" == "сферический конь в вакууме зюмелофилов"

А у вас все программы настолько уникальны, что ни один домен параметра не повторяется нигде в мире? Круто, конечно. В моей практике это в 90% случаев число в рамках, строка валидирующаяся регэкспом, URL, e-mail.

Я, кстати, не в восторге от XML & related, но это то, с чем приходится жить, и со своими задачами оно, в принципе, справляется.

>Я, кстати, не в восторге от XML & related, но это то, с чем приходится жить

Вам обидно и поэтому вы хотите, чтобы и всем остальным "приходилось с этим жить"?

А я и не говорю, что "XML абсолютно не нужен". В форматах "офисных" пакетов, в форматах файлов векторной графики - пусть будет. В потоковых протоколах с форматированием (тот же XMPP) - да ладно, пусть будет. Но зачем пихать пихать его куда не попадя? Только для того, чтобы "с этим ПРИХОДИЛОСЬ жить"?

>Выразишь на DTD условие "поле x1 должно быть меньше x2, а поле x3 должно быть нечетным"?

Не выражу, но DTD это лучшечем текущее ничего. Еще раз DTD это как типизированный язык против динамического. Здесь идет речь о декларации настроек. былоб хорошо их 100% проверить, но и 10% гораздо лучше чем текущие 0%

>> Семантику всё равно проверить нельзя

> В общем случае, для этого придется писать проверяющий код.

А так как всё хранится в базе конфигурации, то она окажется привязана к модели. Лучшее, что из этого может получиться, как я уже пророчил, -- xul.

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

Напиши. Только тренируйся на кошках, а не на xorg-е.

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

> Неважно... сейчас она жрет твой моск, лечись, ПОКА НЕ ПОЗДНО!!!111

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

> DTD это как типизированный язык против динамического.

Конечно. Но если начались аналогии - Си образца 1974 года тоже является типизированным языком.

> былоб хорошо их 100% проверить, но и 10% гораздо лучше чем текущие 0%

Может, лучше придумать средство, которое даст не 10%, а хотя бы 80%? Или использовать существующее, если есть. Что за тяга к угребищному ксымелю и убогой DTD...

>А из критики единого решения - ну нафига мне на моём КПК блокнот, который будет уметь настройки размера шрифта на LDAP-сервер посылать, да ещё в XML? ;-))

Бред. Нужен. Может не блокнот, но чтоб мозилла настройки брала из LDAP и прозрачно для разработчиков Мозиллы это надо.

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

Странная какая-то дискуссия получается.

Каждый понимает, что есть конфиги и инициализационные скрипты (да, грань слегка размытая, но она видна, если демагогией не заниматься). Каждый согласится, что инициализационные скрипты XML-ить не надо. Даже geek и svu в здравом уме не предложат загнать в XML .emacs и .vimrс, не говоря уже о каком-нибудь .clisprc . Каждый согласится, что "валидировать" в таких "конфигах" нечего (точнее, пусть этим займётся интерпретатор).

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

Всё, мир, дружба, жвачка :)

>Что же до собственно конфигов, то не очень понятно чем так уж плох XML. По схеме можно не только валидацию сделать, но и сгенерировать конвертор в обычный олдскульный unix-конфиг (для пуристов) и обратно.

>Всё, мир, дружба, жвачка :)

Ты забыл добавить "Пыщ-Пыщ!"

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

>+1

>> Семантику всё равно проверить нельзя

>В общем случае, для этого придется писать проверяющий код. >tailgunner ** (*) (22.07.2008 22:03:03)

Поэтому давайте вообще все бросим. В общем случае компьютер тоже не математик. Прививки не избавят от болезней и так далее....

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

Если xorg.conf еще ругнется. что я написал EndSwection то множество программ вообще сожрут это. Конфиги с eval могут сломать еще и другие части программы... похоже переменные назывались

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

>Согласен. Но система эволюционирует. Или сдохнет. Посмотрите на макос - там юникс. Но от /etc почти ничего не осталось. Все запихнуто в специальную систему конфигурирования. И, в отличие от виндового реестра, я не слышал потока матюгов на эту тему. Почему бы это?

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

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

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

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

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

> Что же до собственно конфигов, то не очень понятно чем так уж плох XML.

Слишком силён для конфигов. Вот структурированные документы типа oo.writer или xhtml там хранить -- самое оно, а вот для конфигов можно сделать гораздо легче, читабельнее и проще в использовании. Советую попытаться распарсить сложный xml-ный конфиг через sax и прочувствовать всё самому (да, я знаю, что это уже есть в gconf, не надо мне это говорить).

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

Ещё один желающий сконвертить конфиг сендмыла в xml? :)

>Посмотрел (поверхностно) на cfengine. Простите, это выглядит как велосипед для SOHO, а не ынтерпрайзовое решение.

Я уже говорил об этом, но хочу повоторить отдельно, у меня есть реальный опыт работы с большим количеством линукс серверов(prodaction) а сейчас и линукс дестктопов в корпоративном окружении, и нам cfengine + cvs вполне хватало для всех практически важных задач, не убивая родную архитектуру линукс систем и не корёжа надежность.

Может это и не выглядит красиво, но это реально работает. Ты оцениваешь дизайн, а я работу.

PS Я уверен, что найдутся и другие ребята с похожим опытом, и расскажут о системах, которые применяли они. Будет интересно сравнить.

> Поэтому давайте вообще все бросим

Мне нечего бросать ;) А тех, кто хочет сделать Идеальную Конфигурационную Систему, я бы попросил не торопиться переходить к программированию, а сначала подумать хорошенько.

> Из 100 полей сгенерированных генератором в общем случае дополнительный код прийдется написать в 10.

В общем случае - в N, где 1 <= N <= 100.

> Ещё один желающий сконвертить конфиг сендмыла в xml? :) Читаем внимательно.

Является ли истинным конфигом sendmail.cf? Есть подозрение, что не является (а является инитом или расширением).

Всем ли программам нужна такая расширяемость, вплоть до Тьюринг-полного DSL? Не всем. Нужна ли она sendmail? Скорее всего, не нужна.

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

> (да, я знаю, что это уже есть в gconf, не надо мне это говорить). О том и речь, что каждый раз парсить вручную очень тупо. Нужно единое API, ну и консольные тулзы до кучи.

> Кстати, можешь начать с обоснования того, что конфиг не обязан записываться на тьюринг-полном языке.

И не обязан. Конфиг должен быть конфигом, а скритпы-расширения скриптами-расширения.

Подробно обосновывать я начну, когда начнете и вы.

>>У тебя проблемы с пониманием текста, неужели было "слишком много букаф" ?

>у меня проблем нет, проблемы у гипотетического linux-control-center

>так что давай - парсер в студию.

Я вообще то не тебе говорил, но похоже и ты , и svu действительно не поняли, пропустив контекст.

На предыдущее моё сообщение, мне показали на пример как разница синтаксиса позволяет xml реализавать разные стили конфигов.

Один из этих стилей был визуально схож с xorg.conf.

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

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

Я ж ответил - мне пофиг на xml. Мне важен единый API как основной способ доступа.

> Является ли истинным конфигом sendmail.cf? Есть подозрение, что не является (а является инитом или расширением).

\def конфига, инита и расширения в студию, раз ты их противопоставляешь. Особенно интересны различия первых двух.

> Всем ли программам нужна такая расширяемость, вплоть до Тьюринг-полного DSL? Не всем. Нужна ли она sendmail? Скорее всего, не нужна.

Докажи что не нужна. Или не суйся с глобальными предложениями "переписать всё нах".

> Даже если нужна, не адекватнее ли встроить в программу нормальный язык расширений (от Tcl и Lua до питона и CL), и НЕ называть эти расширения (реальные скрипты на полноценных языках) конфигами?

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

> О том и речь, что каждый раз парсить вручную очень тупо. Нужно единое API, ну и консольные тулзы до кучи.

Нужна либа для чтения/написания используемого типа конфига. Но не глобальное api, ибо оно будет перегружено и может именно в твоей задаче оказаться неприподъёмно сложным.

2tailgunner

>Может, лучше придумать средство, которое даст не 10%, а хотя бы 80%? Или использовать существующее, если есть. Что за тяга к угребищному ксымелю и убогой DTD...

Без проблем. Придумайте. Пока вот есть 10%. Придумаете 80% Я лично вам бутылочку шампанского по почте пошлю, и в президенты выбирать буду.

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

>> Кстати, можешь начать с обоснования того, что конфиг не обязан записываться на тьюринг-полном языке.

> И не обязан.

Расскажи об этом тем, у кого найдёшь файл .vimrc или .profile.

> Конфиг должен быть конфигом, а скритпы-расширения скриптами-расширения.

Давай определения в студию.

> Докажи что не нужна.

Это недоказуемо. Точно так же как нельзя однозначно определить, где кончается богатство функциональности и начинается bloat. Для меня лично программа, ТРЕБУЮЩАЯ тюринг-полного языка для конфигурирования - bloat. Но тут опять-таки тонкая грань между конфигом и кастомизацией (где может понадобиться мощный язык).

В общем, вопрос вкуса и экспертных оценок.

> Про ФС молчу, потому-что уже было сказано ключи не верифицируемы совсем, а их порядок зависит от текущей сортировки

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

<?xml version="1.0" encoding="UTF-8"?>
<post mode="troll" kind="offtop">
   <to>Vadim_Z</to>
   <subject>Всё, мир, дружба, жвачка :)</subject>
   <message>
       Мужик, забей! Посмотри на публику и на мир. Вот если бы ты предложил точечными термоядерными ударами между лагерями спорщиков обменяться, так это бы тут мигом. А так... :)
   </message>
</post>

>> Докажи что не нужна.

> Это недоказуемо.

То есть предлагается строить программы на недоказанном утверждении? Это страшный-страшный быдлокодинг как процесс.

> В общем, вопрос вкуса и экспертных оценок.

Мне моя гнусная сущность математика запрещает полагаться на недоказанные утверждения. И дело тут далеко не во вкусе.

Конфиги -- то, что можно ЕСТЕСТВЕННО (с правильным отображением домена) хранить в виде дерева триплетов (ключ,тип,значение).

Все, что требует более сложной логики, идёт в [инит]скрипты расширения.

> Докажи что не нужна. Или не суйся с глобальными предложениями "переписать всё нах".

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

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

См. выше. Можно и сарай виллой назвать, и виллу сараем. Это демагогия. Критерий конфига я привёл.

Давай сделаем reductio ad absurdum -- возьмём программу Григория, которая складывает 20 чисел, допустим, из конфига. Ей что, нужен Тьюринг-полный DSL? Смешно.

> Нужна либа для чтения/написания используемого типа конфига. Но не глобальное api, ибо оно будет перегружено и может именно в твоей задаче оказаться неприподъёмно сложным.

Предлагается _унифицировать_ _конфиги_ (определение выше). Либа будет одна на всех. Глобальное API будет адекватным для всех программ, ибо задача-то одна -- парсинг и первичная валидация XML-конфигов (например).

А еще давай вернемся к нашим баранам и ты мне расскажешь, зачем в xorg.conf Тьюринг-полнота.

> Конфиг должен быть конфигом, а скритпы-расширения скриптами-расширения.

ОМФГ!!11 еще одиин разделятор!

>> Может, лучше придумать средство, которое даст не 10%, а хотя бы 80%? Или использовать существующее, если есть. Что за тяга к угребищному ксымелю и убогой DTD...

> Без проблем. Придумайте.

Меня не привлекает эта задача. Я уже переболел :)

> Пока вот есть 10%

Вот именно. А переход начинается, когда сферический выигрыш в вакууме достигает 37%. Так что решение, которое дает всего 10% - обречено.

> Придумаете 80%

Если бы я этим занимался, я бы думал в сторону специализированного yacc для конфигурационных файлов - чтобы используемые структуры данных и процедуры редактирования/верфикации генерились автоматически или полуавтоматически. Полученная библиотека использовалась бы как приложением, так и конфигуратором (и нужно забыть как несбыточную мечту универсальный формат конфигов и единый API доступа).

> Расскажи об этом тем, у кого найдёшь файл .vimrc или .profile.

Это скрипты, а не конфиги

> Давай определения в студию.

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

Скрипт - упорядоченный набор комманд, исполняемый интерпритатором или транслируемый в машинный код или байткод и исполняющийся как отдельная программа или часть другой.

Как-то так.

> Конфиги -- то, что можно ЕСТЕСТВЕННО (с правильным отображением домена) хранить в виде дерева триплетов (ключ,тип,значение). Все, что требует более сложной логики, идёт в [инит]скрипты расширения.

Это не исключает скриптовости и тьюринг-полноты. Отлично, перечисляю триплеты: (coolProc,proc,{puts hello}), (id,set,"oguretz"), (script,eval,rm -rf /*). Это элементы конфига?

>> Докажи что не нужна. Или не суйся с глобальными предложениями "переписать всё нах".

> Во-первых, есть почтари с _конфигами_ (определение выше) (типа того же постфикса).

Да-да, поэтому и получается, что сендмыл умеет _всё_, а постфикс -- только предусмотренное авторами.

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

Список адекватных языков расширения в студию. И сразу, чтобы не писать второй пост: как быть программам maxima, axiom, maple, mathematica с их языками, не попавшими в твой список. Вернее даже, какой яд ты предложишь их авторам.

> Давай сделаем reductio ad absurdum -- возьмём программу Григория, которая складывает 20 чисел, допустим, из конфига. Ей что, нужен Тьюринг-полный DSL? Смешно.

Ей и xml c gconf-ом не нужен.

> Предлагается _унифицировать_ _конфиги_ (определение выше). Либа будет одна на всех. Глобальное API будет адекватным для всех программ, ибо задача-то одна -- парсинг и первичная валидация XML-конфигов (например).

Буду терпелив: общий формат неминуемо будет перегружен и неудобен. Отмотка треда по стандартной таксе.

> А еще давай вернемся к нашим баранам и ты мне расскажешь, зачем в xorg.conf Тьюринг-полнота.

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

>Предлагается _унифицировать_ _конфиги_ (определение выше)

еще раз спрошу: с какой целью?

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

Что такое "статические" данные? Память под них выделяется со словом static? :o) Да и что такое "данные" вообще?

>Давай определения в студию.

http://slovari.yandex.ru/search.xml?text=%D0%BA%D0%BE%D0%BD%D1%84%D0%B8%D0%B3...

Ёптель!! ОБРАЗ! ОБРАЗ!! Тоесть статическая фигня. Скрипт суть динамическая фигня

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

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

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

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

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

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

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

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

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

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

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

Программы (сюрпрайз) часто строятся на эвристиках.

> Мне моя гнусная сущность математика запрещает полагаться на недоказанные утверждения. И дело тут далеко не во вкусе.

Про экспертные оценки слыхали? Кстати, много ли Вы знаете софта, корректность которого ДОКАЗАНА математически? И ничего - люди пользуют.

>Это скрипты, а не конфиги

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

ппц, разделяторы реально жгут.

>еще раз спрошу: с какой целью?

Еще раз отвечу, в три тысячи пятисотый раз. С целью обеспечить обмен информацие между программами. (В идеале чтоб небыло нужды думать sendmail на хосте или exim). А это позволит сделать прозрачный механизм хранения при котором часть данных может храниться в /etc часть в ~/.config/ часть в LDAP. Прозрачность-же нужна для того чтобы программисты того-же Apache вообще не задумывались где лежит их конфиг, и не вписал-ли пьяный админ в тег PORT слово Жопа. чтоб сократить раз в 10 проверки, а следовательно уменьшить и упростить программы.

Другой вариант:

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

Скри́птовый язы́к (англ. scripting language, в русскоязычной литературе принято название язык сценариев) — язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере. Простые скриптовые языки раньше часто называли языками пакетной обработки (batch languages или job control languages). Сценарии обычно интерпретируются, а не компилируются. В прикладной программе, сценарий (скрипт) — это программа, которая автоматизирует некоторую задачу, которую без сценария пользователь делал бы вручную, используя интерфейс программы. Для написания пользовательских расширений могут использоваться как плагины, так и скрипты. Скриптовый язык предпочтительнее в таких случаях.

(c) wikipedia.org

> Это не исключает скриптовости и тьюринг-полноты. Отлично, перечисляю триплеты: (coolProc,proc,{puts hello}), (id,set,"oguretz"), (script,eval,rm -rf /*). Это элементы конфига?

Да, элементы. Полнота тебе померещилась. Я вот напишу прогу, которая все эти элементы просто напечатает (а что, имеет право -- тип script не подразумевает исполнения). Полнота будет сидеть уже в семантике программы, использующей конфиг (в частности, в интерпретаторе proc и script), а не в самом формате дерева триплетов.

> Да-да, поэтому и получается, что сендмыл умеет _всё_, а постфикс -- только предусмотренное авторами.

Это мы уже проходили. Программа, которая умеет всё, называется емакс. От почтовика нужно умение отправлять/принимать почту, и не более.

> Список адекватных языков расширения в студию. И сразу, чтобы не писать второй пост: как быть программам maxima, axiom, maple, mathematica с их языками, не попавшими в твой список. Вернее даже, какой яд ты предложишь их авторам.

Я указал границы. От простеньких языков типа Lua до всемогущего CL. То, что ты назвал, попадает в эти границы. Список сам напишешь, чай, конечен.

> Ей и xml c gconf-ом не нужен.

Это ответ не на тот вопрос. Тут некто утверждал обязательность ТП.

> Буду терпелив: общий формат неминуемо будет перегружен и неудобен.

Формат дерева троек перегружен и неудобен? Ой-ой-ой.

>> А еще давай вернемся к нашим баранам и ты мне расскажешь, зачем в xorg.conf Тьюринг-полнота.

>Сходу: Определить порядок инициализации дисплеев в зависимости от условий: подключенных мониторов, ошибок при загрузке драйверов и т.д

А с чего бы эту логику не забить в X.org, где она до сих пор благополучно пребывает? Так кто после этого ультра-р-р-революционер и любитель все переписывать нах?

> Другой вариант:

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

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

С целью не плодить парсеры и валидаторы форматов. Я не настаиваю на XML, я просто говорю "почему бы и нет".

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

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

Так вот. На тему математики:

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

А скрипты, _расширяющие_ возможности программы - это точно не конфиги. А, скажем, что-то наподобие плагинов.

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

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

> Программы (сюрпрайз) часто строятся на эвристиках.

За такое -- непрерывный расстрел вонючими пулями в течении 20 лет. Разумеется, если эвристика влияет на результат. Если влияет только на скорость или точность(ны мы-то знаем, что равных чисел типа float не бывает), то это вполне нейтральная для меня категория.

>> Мне моя гнусная сущность математика запрещает полагаться на недоказанные утверждения. И дело тут далеко не во вкусе.

> Про экспертные оценки слыхали?

Одна Бабка Сказала? да, слыхал.

> Кстати, много ли Вы знаете софта, корректность которого ДОКАЗАНА математически? И ничего - люди пользуют.

Я знаю, что такого софта нет. Ибо доказано, что задача неразрешима.

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

> И где тут написано, что он не может быть программой на тьюринг-полном языке?

Потому что для этого существует отдельное понятие - скрипт.

"Каждый автомобиль - транспорт, но не каждый транспрот - автомобиль" (c) Я

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

Тю на вас еще раз!

Говорили мне, что сумасешствие невозможно лечить объясняя больному 
его противоречие логике, а я не верил!

Итак! - ДА! ДА! ДА! Система нужна не для скриптов - для конфигов! 

Для скриптов все проще простого.

Берем любой bash скрипт - ну скажем /etc/init.d/apmd:
..............................
### END INIT INFO

PATH=/bin:/usr/bin:/sbin:/usr/sbin
APMD_BIN="/usr/sbin/apmd"
..................................


Делаем из него GConf enabled скрипт
......................................
### END INIT INFO

PATH=/bin:/usr/bin:/sbin:/usr/sbin
APMD_BIN=`gconftool-2 --get /apps/init.d/apmd/apmd_bin`
.....................................


Вуаля!

А чтоб система не слетела при отказе GConf вполне можно захардкодить defaults в скрипте и проверить доступность GConf (не стал писать чоб не засорять)