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

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

>Сколько угодно. Подходящими тулзами. Вы выглядите как строитель, у которого один инструмент - топор. И больше ничего. Конечно, когда Вы построите Кижи - люди веками будут приходить любоваться Вашим творением. Но проблему массового жилья для населения Вы не решите.

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

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

>> Ни откуда не следует, что программист допускает в своей работе меньше ошибок, чем админ.

>Следует - в опенсорцевой модели. "Закон Торвальдса" слыхали?

У меня есть опыт работы программистом, программа написанная мной и моими друзьями до сих пор работает на АЭС(года где то с 94, ага), я знаю на своём примере, что такое программа, которая не учитывает запросы людей которые её используют.

И потом наиболее массовые тестеры программ, по крайней мере системных - админы.

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

Ну считай, что скриптовый конфиг -- это один триплет типа "скрипт" с именем "id". А как его применять решает сама прорамма.

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

> От почтовика нужно умение отправлять/принимать почту, и не более.

Ты не в теме. Спам режет/антивирусом проверяет/отлупы о несуществующих адресах тоже емакс отправляет? Или всё-таки mta?

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

То есть все языки? Да, тут придраться действительно не к чему :)

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

В общем случае обязательно. Пока не доказано обратное.

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

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

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

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

Разницу между "переписать всё нах" и "переписать отдельную программу" видишь? Да и устраивает меня xorg.conf в ег текущем виде, но раз уж пошла такая пьянка...

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

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

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

> Ну считай, что скриптовый конфиг -- это один триплет типа "скрипт" с именем "id". А как его применять решает сама прорамма.

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

>да кто ж тебе мешает? fuse-gconf какой-нибудь и редактируй свои конфиги в любимом емаксе. Ну а то, что неправильный конфиг не будет сохраняться с мотивацией "permission denied" - так это только плюс

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

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

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

>Еще раз отвечу, в три тысячи пятисотый раз. С целью обеспечить обмен информацие между программами. (В идеале

в три тысячи пятисотый раз ты повторил ряд общих фраз. Из серии "постоить такую башню..."

Существует ли какая-либо реальная, не надуманная задача, требующая реализации этого инструмента?

ps: а с хрена ли программисты того-же Apache вообще заботились судьбой пьяных админов и жопой в теге PORT??

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

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

И какой вывод? "Каждый скрипт - конфиг, но не каждый конфиг - скрипт"? Или наоборот?

>> и оказалось, что он парсится в libc.

>Что дичь (если правда - надо сырцы проверить). Не дело libc парсить конфиги.

выше я ссылался на тебя, на твой ответ когда я обсуждал работу программы mount.

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

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

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

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

UPD: коряво последовал, лучше так: "яблоко не может быть зелёным, ведь 'зелёный' -- это отдельное понятие"

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

Объясняю еще раз: скрипт - это описанный тем или иным образом алгоритм. Файл с настройками - всего лишь список именованных значений, не более того.

Предупреждая вопрос "а чем этот скрипт отличается от конфига":

#!/usr/bin/perl
$a = 10;
$b = 20;

Ответ: какой скрипт не имеет логического смысла, т.к. не содержит в себе описания алгоритма.

> Ну считай, что скриптовый конфиг -- это один триплет типа "скрипт" с именем "id". А как его применять решает сама прорамма.

Специально на этот случай я писал про естественное отображение предметной области на формат. Да, каждый раз надо решать, хватит ли "дерева триплетов" или нет. Если человек неправильно отображает, значит, пусть учится правильно. Либо он просто саму область неправильно понимает.

> И? Где ты разбил в пух и прах мои надежды на текстовый конфиг и применения языка программирования для его записи.

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

> В общем случае обязательно. Пока не доказано обратное.

А как насчёт бритвы Оккама? Конфиги в вышеуказанном смысле проще и безопаснее. Правильнее наоборот -- ТП не нужно, пока не доказано (точнее, не следует естественным образом из предметной области) обратное.

> Ты не в теме. Спам режет/антивирусом проверяет/отлупы о несуществующих адресах тоже емакс отправляет? Или всё-таки mta?

Отлуп об адресе -- это относится к принять/отправить. А проверка почты и спаморезка не функция mta. Не надо нарушать модульность.

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

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

Причём никто не настаивает именно на XML -- речь идёт о _формате_, ему семантически эквивалентном. Пожалуйста, хоть Sexp, хоть JSON, хоть plain text, лишь бы прикрутить к ним ту же семантику.

> Разницу между "переписать всё нах" и "переписать отдельную программу" видишь? Да и устраивает меня xorg.conf в ег текущем виде, но раз уж пошла такая пьянка...

Возвращаю претензию. Я сказал про sendmail, а ты мне про "переписать всё нах".

> И какой вывод? "Каждый скрипт - конфиг, но не каждый конфиг - скрипт"? Или наоборот?

Предоставлю поиск правильного ответа вашему рассудку.

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

> То есть все языки? Да, тут придраться действительно не к чему :)

Ну да, все. И даже свои можешь придумать :) Лишь бы они были адекватны задаче.

> UPD: коряво последовал, лучше так: "яблоко не может быть зелёным, ведь 'зелёный' -- это отдельное понятие"

Понятие яблока не является подмножеством понятия зеленый.

> Чудо, не дуплет - триплет. Нафига в триплете тип? Это и есть зачаточная валидация. А больше и не надо. Можно былоб туда regex еще засунуть.. но к сожалению я не знаю такого механизма

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

>>Ты описал именно меня, именно мне приходится ежедневно админить много машин, но у меня проблемы именно с xml конфигами, именно их понимать и править трудно, они удобны только для программистов создающих эти конфиги

>Ты фанатик. При слове XML у тебя сразу отрубается мозг. XML конфиги на 1-й машине может и сложнее править чем INI Like. Но вот для 10 машин они уже дают удобство. Какое?

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

Ны ты прям Пифагор, всё видишь насквозь.

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

Сначала определись, меня надо поносить или со мной надо спорить, а то вместе это как то нескладно получается

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

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

Тебе не только я указал на кривость твоих слов.

> Объясняю еще раз: скрипт - это описанный тем или иным образом алгоритм. Файл с настройками - всего лишь список именованных значений, не более того.

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

// ушёл спать

>> И какой вывод? "Каждый скрипт - конфиг, но не каждый конфиг - скрипт"? Или наоборот?

> Предоставлю поиск правильного ответа вашему рассудку.

за неимением собственного

>> UPD: коряво последовал, лучше так: "яблоко не может быть зелёным, ведь 'зелёный' -- это отдельное понятие"

> Понятие яблока не является подмножеством понятия зеленый.

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

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

>Это вы не нужны если слабо осознаете потенциальные траблы данного подхода.

Прими мужественное решение, определись ты споришь/убеждаешь или ты поносишь ?

>Предоставлю поиск правильного ответа вашему рассудку.

А толку? Мой рассудок не знает, какой ответ для ВАС правильный:)

Вот пример реального конфига:

[chapter0]
item1=5
item2=4
item3=8

[chapter1]
LIKE=chapter0
item2=7

"LIKE=..." - наследование. Этос скрипт или конфиг.
По мне так конфиг, но по вашему - нет, потому как фактически "LIKE=..."
вызывает действие по инициализации переменных chapter1 из значений таковых chapter2.

Проведите грань:)

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

>мнээ.. что, в make xconfig / make gconfig / make qconfig все опции ведра ручками хардкодят? или всё-таки есть один список с опциями, из которого этот гуй генерится?

Ты никогда не сталкивался с тем, что при одинаковых выбранных ключах конфига разными *config, размер скомпилированного ядра может отличатся раза в два ?

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

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

> за неимением собственного

Анонимные тролли дружным шагом идут на **й.

> Если человек неправильно отображает, значит, пусть учится правильно. Либо он просто саму область неправильно понимает.

Покажи на примере сендмыла как правильно разбить в триплеты без потери функциональности, раз ты это умеешь. Двадцать лет хватит?

> Отлуп об адресе -- это относится к принять/отправить. А проверка почты и спаморезка не функция mta. Не надо нарушать модульность.

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

> А как насчёт бритвы Оккама? Конфиги в вышеуказанном смысле проще и безопаснее. Правильнее наоборот -- ТП не нужно, пока не доказано (точнее, не следует естественным образом из предметной области) обратное.

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

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

метаинформация, описывающая view и contorller. Например "password.enabled = (authorization.value == true)"

> Возвращаю претензию. Я сказал про sendmail, а ты мне про "переписать всё нах".

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

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

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

>Анонимные тролли дружным шагом идут на **й.

Боюсь, если анонимные тролли дружным шагом, кованым сапогом пройдутцца по твоей пипке...

> Проведите грань:)

Ну сноска на другой блок. Ну линк. Где описание алгоритма?

> Боюсь, если анонимные тролли дружным шагом, кованым сапогом пройдутцца по твоей пипке...

А потом проснутся...

> Покажи на примере сендмыла как правильно разбить в триплеты без потери функциональности, раз ты это умеешь. Двадцать лет хватит?

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

И, повторюсь, я не призывал его переписывать. Само помрёт, да.

>> А как насчёт бритвы Оккама? Конфиги в вышеуказанном смысле проще и безопаснее. Правильнее наоборот -- ТП не нужно, пока не доказано (точнее, не следует естественным образом из предметной области) обратное.

>Конфиги в тп формате _уже_ используются и надо не потерять существующую функциональность. Так что увы.

Путаем-с. Я обсуждал не переписывание существующих программ, а проектирование новых. Так вот, для новых дефолт -- неТП.

> метаинформация, описывающая view и contorller. Например "password.enabled = (authorization.value == true)"

ну мб. можно и её включать, но она должна быть факультативной, как и соотв. части API.

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

>Ну сноска на другой блок. Ну линк. Где описание алгоритма?

print "Hello"

"Где описание алгоритма?" (с) Gris

>Проблема разделения прав на конфигурацию и пр. всё равно существует и лучше её решать единообразно.

Она уже решена: с помощью ФС

FS -- недостаточно гранулярный механизм, увы...

>>Ну сноска на другой блок. Ну линк. Где описание алгоритма?
>print "Hello"

>"Где описание алгоритма?" (с) Gris

Вызов функции print(...) с параметром "Hello". Вполне конкретная последовательность _действий_, правда только из одного _действия_.

> Она уже решена: с помощью ФС

А валидация правильности данных на основании некоторой схемы и обеспечение строгого порядка следования ключей решены на уровне ФС? Не создавая дополнительных костылей?

>FS -- недостаточно гранулярный механизм, увы...

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

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

Можно вспомнить, как работает тот же subversion. У него _своя_ аутентификация и права доступа (если речь не идёт о file:// и ssh:// репах), т.е. система сделана поверх fs. Тут, мне кажется, всё еще сложнее.

>А валидация правильности данных на основании некоторой схемы и обеспечение строгого порядка следования ключей решены на уровне ФС?

"Очерёдность следования ключей" - не нужна, потому как неважна. Очерёдность следования команд (или очерёдность наследования, если угодно) решается в ФС элементарно и уже много лет - например, смотрите, SysV инициализацию.

> Разумеется, если эвристика влияет на результат.

Бывает и так. И ничего - годится для большинства случаев.

> Я знаю, что такого софта нет.

Как же Вы, математик, живете?

Будьте проще - смиритесь с миром, где практически весь софт good enough - и не более того.

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

Это вам кажется.

>Можно вспомнить, как работает тот же subversion. У него _своя_ аутентификация и права доступа (если речь не идёт о file:// и ssh:// репах), т.е. система сделана поверх fs. Тут, мне кажется, всё еще сложнее.

вы не в теме. Подсказка: в git нет своей "аутентификации и прав доступа".

> "Очерёдность следования ключей" - не нужна, потому как неважна.

А мне бывала нужна. Что делать?

Я про subversion, а не про git говорил.

http://svnbook.red-bean.com/en/1.4/svn.serverconfig.svnserve.html#svn.serverc...

>Вызов функции print(...) с параметром "Hello". Вполне конкретная последовательность _действий_, правда только из одного _действия_.

LIKE=chapter0

Переход в секцию chapter0, применение значений параметров из этой секции для секции chapter1

>А мне бывала нужна. Что делать?

очерёдность следования нужна только если что-то зависит от предидущего. А это уже не "статические данные для конфига", здесь уже логика - значит не конфиг а скрипт(?) :)

>Я про subversion, а не про git говорил.

Ну, дык, а я тебе говорю про конфиги, а не про систему контроля версий. это ортогональные понятия. конфиги можно и в систему контроля версий положить - довольно удобно: можно "откатывать" и "накатывать" конфиги на определённый тег/ревизию/дату/etc.

> Переход в секцию chapter0, применение значений параметров из этой секции для секции chapter1

Обычная декларация. Действия нет.

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

Если совсем тупо, то я не знаю, что делать, если одну часть конфига некий юзер X имеет право редактировать, другую -- не имеет, а третью -- даже смотреть не может. Что, разбивать конфиг на 3 части?

> очерёдность следования нужна только если что-то зависит от предидущего. А это уже не "статические данные для конфига", здесь уже логика - значит не конфиг а скрипт(?) :)

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

К примеру, а строю последовательность из проксей, скажем для SOCKS. Порядок соединения должен быть таким: proxy1.some.host, proxy2.some.host, proxy3.some.host. 

Простейшее описание на XML:

<proxySequence>
   <proxy>proxy1.some.host</proxy>
   <proxy>proxy2.some.host</proxy>
   <proxy>proxy3.some.host</proxy>
</proxySequence>

Пример может и не самый удачный, но идею более менее обрисовывает.