Дистрибутив GENTOO каталог /etc/conf.d

Ура товарищи! Наконец-то этой горе мурорных конфигов придёт конец! Правда у ГНОМа уже есть реестр, зачем новый писать-то?

> Писать свой парсер конфига - не такой уж гемор

Да-да... работать исключительно в консоли - тоже "не такой уж гемор", если подумать. Зато тру и элитно.

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

Тьфу млин... сколько ж я времени тут зря потратил? Сказано уже - один ключ это один файл, какие права на файл поставишь, такие и будут. Какой еще демон?

> Скорость доступа к этому реестру. Ниже чем отдельной проги к совему конфу

Единственный комментарий, имеющий хоть какой-то смысл. Да, будет. Хотя и то не всегда - рискну предположить, что XML'ные конфиги читаются медленней. Однако ж конкретных цифирь нет - есть предложение провести тесты и посмотреть на результаты. Или вы предпочитаете теоретизировать?

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

А в случае с обычными юниховыми конфигами, что, не так же? Кстати вот еще что: если у вас накрывается тот же /etc/passwd, то накрывается _целиком_. А здесь загнется скажем один ключ с домашним каталогом пользователя. Где легче восстановить будет?

Мать, мать, мать привычно отозвалось эхо... То что раньще считалось круто в линухе стараются прибить. Нахрен мне нужен реестер? Я знаю где что какая софтина хранит, где ее конфиги, где база компонент для orb где еще что. Теперь пожалуйте все спихнули в одно место, запихнули в xml, который не достаточно удобно из обычного редактора править. И еще все радуются. И никто не замечает что, насколько я вижу, это не один файл а структура каталогов. Я уже столкнулся с этой хренью. GConf - структура каталогов, коментарии в xml с локализацией, но пока найдешь что это за ключ, что он дает злость пробивает. Личное мнение - реестр на линуксе НЕ НУЖЕН, давайте тогда еще что у MS возьмем? установку софта с помощью сторонних инсталяторов? Или может passwd/shadow/tcb в реестр запихнем ?

> Правда у ГНОМа уже есть реестр, зачем новый писать-то?

http://registry.sourceforge.net/#compared

> Теперь пожалуйте все спихнули в одно место, запихнули в xml

Бл#@дь!!!! (вы меня так точно матом приучите объяснять)

@#$%# НУ ПРОЧИТАЙ ТЫ ТРЕД!!!!

НЕТУ ТАМ XML! НЕТУ!! НЕТУ!!!!!!!!

> И никто не замечает что, насколько я вижу, это не один файл а структура каталогов.

Все это прекрасно замечают.

Кстати, с нахождением ключей в gconf'е у меня никогда проблем не было. Правда, править его ручками, в обход gconf-editor, действительно неудобно. Но тут такого не наблюдается.

> Или может passwd/shadow/tcb в реестр запихнем ?

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

2 rk

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

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

2 svu: Респект тебе за отстаивание правильной точки зрения. Блин, ну ты все-таки какой-то добрый и вежливый слишком. Как та чернокожая американка из "полицейской академии", котороя все пищала: "Будьте добры, отойдите, пожалуйста". Тебе надо один раз назвать дебилов дебилами. Громко, смачно и матом желательно :))... Ну вот не хотят они читать. Они только слово registry в заголовке прочитали... :)

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

2 Antichrist: Виталий, мне кажется, что svu абсолютно прав. Проблема скриптовых конфигураторов особо не пересекается с проблемой конфигов. Наоборот даже. Их совместное и красивое сосуществование - это и есть хорошая и, как мне кажется, *осуществимая* с технической точки зрения цель.

> Дистрибутив GENTOO каталог /etc/conf.d Там находятся всего пару опций и линки на полноценный конфиг.

> Единственный комментарий, имеющий хоть какой-то смысл. Да, будет. Хотя и то не всегда - рискну предположить, что XML'ные конфиги читаются медленней. Однако ж конкретных цифирь нет - есть предложение провести тесты и посмотреть на результаты. Или вы предпочитаете теоретизировать? Основная моя мысль заключалась в первом доводе (про вред стандартизации такой интимной вещи как конфыг).

> А в случае с обычными юниховыми конфигами, что, не так же? Кстати вот еще что: если у вас накрывается тот же /etc/passwd, то накрывается _целиком_. А здесь загнется скажем один ключ с домашним каталогом пользователя. Где легче восстановить будет?

Вобще то чем больше файл и чем чаще он используется - тем больше вероятность того что он повредицца. А теперь сравни частоту использования и размер этого реестра и /etc/passwd

>> Писать свой парсер конфига - не такой уж гемор

Да-да... работать исключительно в консоли - тоже "не такой уж гемор", если подумать. Зато тру и элитно.

Да ну? Если ты не можешь даже парсер кофига написать, то какой же ты начлен кодер? Ну ладно, лениво тебе - так заюзай парсер того же самого апача или другой любой проги. Они там (парсеры) всегда в отдельном сорце, часок посидишь и прикрытишь к своей проге. Благо есть такая вещь как GPL :)

> Единственный комментарий, имеющий хоть какой-то смысл. Да, будет. Хотя и то не всегда - рискну предположить, что XML'ные конфиги читаются медленней. Однако ж конкретных цифирь нет - есть предложение провести тесты и посмотреть на результаты. Или вы предпочитаете теоретизировать?

Основная моя мысль заключалась в первом доводе (про вред стандартизации такой интимной вещи как конфыг).

> А в случае с обычными юниховыми конфигами, что, не так же? Кстати вот еще что: если у вас накрывается тот же /etc/passwd, то накрывается _целиком_. А здесь загнется скажем один ключ с домашним каталогом пользователя. Где легче восстановить будет?

Вобще то чем больше файл и чем чаще он используется - тем больше вероятность того что он повредицца. А теперь сравни частоту использования и размер этого реестра и /etc/passwd

>> Писать свой парсер конфига - не такой уж гемор

Да-да... работать исключительно в консоли - тоже "не такой уж гемор", если подумать. Зато тру и элитно.

Да ну? Если ты не можешь даже парсер кофига написать, то какой же ты начлен кодер? Ну ладно, лениво тебе - так заюзай парсер того же самого апача или другой любой проги. Они там (парсеры) всегда в отдельном сорце, часок посидишь и прикрытишь к своей проге. Благо есть такая вещь как GPL :)

Re:

> Ну ладно, лениво тебе - так заюзай парсер того же самого апача или другой любой проги. Они там (парсеры) всегда в отдельном сорце, часок посидишь и прикрытишь к своей проге. Благо есть такая вещь как GPL :)

Педантичный корректировк: апачевские парсеры идут под Apache Public License, не под GPL

Не прокатит такая идея в unix

> Все таки такие каталоги будет неудобно править руками. Это однозначно.

Куда там неудобно - просто невозможно конфиги будет править без особого редактора. Прощай $EDITOR.

Эта идея лишь на поверхностный взгляд может показаться хорошей, а на поверку - вредной. Не знаю как вам, а мне намного проще и быстрее редактировать один *.conf или там ~/.Xdefaults файл, чем тысячи миниатюрных. Или может вы готовы продаться полностью ГУЕвым редакторам?

Проблемы с доступом к директориям/файлам решать надо будет. Так один файл надо chmod/chown, а так много файлов и директорий, причем таких, что добавляются в новой версии. Непосильная задача вручную держать тысячи ключей под контролем и следить, чтобы часть из них была групы modem, а часть sound при обновлении программы. Люди поручат всё это автоматике, здравствуй Windows.

Проблемы версий решать надо будет. Программа добавила пару опций и убрала другие, что делать со всеми /etc/registy/users/*/sw/програм/* файлами? И "изобретут" решение держать конфиги для разных версий, и вместо program делать program-x.y.z. И будет свалка и кошмар. Решая одну проблему порождаешь десять. Лучше не пытаться ничего решать, особенно то, что работает десятилетиями.

Опять же, парсить значение ключа программа всё ещё сама должна, а ведь найдутся дурные головы, кто захочет файл ключа "усовершенствовать" и держать там тип ключа, а тип ну никак не может быть чем-то иным чем класс, сами понимаете, объекты пойдут, и XML еще покажется одним удовольствием по сравнению с тем как тот самый файл с <DATA> захотят усовершенствовать. И можно будет такой файл лишь через библиотеку правильно прочесть.

Ну, а разработчиков програм и вовсе спрашивать не будем как им удобнее из конфига читать, есть же библиотека на C (хорошо хоть не на C#). А захочешь программу на Perl/Ruby/Python писать, пользуйся их binding-ами. Не зря же mono портируют, надо его сделать базисной частью системы тоже.

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

Еще проблема, раньше /home монтировать отдельно можно было и шарить между системами, а теперь часть пользовательской информации в /etc сидит. Что же теперь ещё и /etc/registry/users монтировать/шарить отдельно? Мнда...

В общем, неумная идея - один файл в сотни файлов превратить в разных под-директориях с некоторым количеством метаданных (читай мусором). Так хоть можно "diff" сделать, или "cat >>". или "grep key". А для деревьев и <data> файлов нет пока unix утилит. Не было надобности так усложнять всё до сих пор.

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

Итог, registry - ненужное усложнение/нагромождение существующей системы в ущерб удобству, порождающее кучу новых проблем.

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

А-ха. А потом еще и права отберем на завершения любых процессов. И будет нам всем счастье. Виндовое.

svu, прекрати позориться. Тебя же дети читают.

>А также по остлеживанию изменений, которые кто-то при помощи ... разумеется, ed, ручками внес в /etc/X11/XF86Config. Жду предложений с нетерпением.

На yast посмотри.

То есть ты разведешь помойку - половина в "реестре", половина в конф-файлах... Ну на хрена? Есть текстовый файл - сиди и унифицируй...

Очень хочу взглянуть на унифицированный конфиг сендмейла.

Войди в конф-файлы и сделай себе дубликат перевода

svu, а как на тему раскладок (чую, это у тебя больное место - gnome, понимаешь...) в КДЕ? Я тут проверял недавно - у них все работает. Выбирается гуем.

Кроме раскладок тебя еще что не устраивает?

> Но увидеть resolv.conf или /etc/hosts в XML-формате

/etc/hosts даже Microsoft поленилась в реестр засунуть. Или в XP уже засунула?

А-ха. А потом еще и права отберем на завершения любых процессов. И будет нам всем счастье. Виндовое.

svu, прекрати позориться. Тебя же дети читают

Желающихпересеть на Линукс виндузятников-миллионы.Вас всего тысячи.:) Виндузятникам удобен реестр.Ты это понимаешь? А пара тысяч это фигня по сравнениюс миллионами. Переучитесь.;))

Да уж, лучше бы взять да etc к единому стандарту привести... А уж если кому то очень хочется, так можно ж было б тулзу написать - 'эмулятор реестра' какой-нить... Эх...

> а конфигурялка сквида+сквидгарда тоже на раз-два делается ?
бинд+dhcp ? postfix+ldap+courier ?

А чего все в конфигурялки ГУЕвые уперлись? Для неё нужен банальный парсер текстового файла. Один для всех! Или чем-то станет легче, если в самбе и апаче, к примеру унифицировать параметр HOSTNAME? У вас с netbios name непреодолимые трудности? Конфигурятор сквида должен непременно парсить и исправлять что-то в smb.conf?

> Ну если ИБМ это куча пионеров, то действительно не стоит напрягаться...

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

> Сохраняли. Через ...

Ну и кто они после этого?

> Посмотрите код хоть одной гуевой конфигурялки кроме гномовской. Они почти всегда сохряняют ВЕСЬ XF86Config - ни одна, насколько я помню (могу ошибаться, но не сильно), не работает с кусочком, слепо игнорируя остальное.

И зачем это всё? Разве требуется при конфигурении клавы лезть в секцию драйвера дисплея? Или от этого сильно зависят фонтпафы?

> Я хочу API конфигурирования, а не API чтения файлов.

Так напиши его или используй готовое.

> Я не хочу писать полноценные гуялки-конфигурялки на баше.

А я этого и не предлагал. Да и не понимаю кому может придти в голову писать ГУЯЛКУ на баше.

> Угу. Только у меня они называются "функции", а не "костыли". И позволяют, как тут было отмечено, разделять конфигацию и код.

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

Что сложного в написании ГУЕты к smb.conf? Да любой студент за полдня сделает тебе это хоть в 1С! (кстати, прикольно) Та же обработка лихко перенастраивается на конфигуряние сквида.

> KISS - Keep It Simple Stupid
>
> and - отсутствует, так как это обращение!

Обиделся, да, что тебя забыли?

> Только дайте разработчику способ стандартным образом доступаться к файлам.

Этих способов сегодня не существует?

> Вообще(!) не думая о формате файлов.

Ага. Далее ... "не думая о том что он конфигурит, зачем" ... Думать надо всегда и обо всём, иначе получится поделие коих навалом! А "разработчикам" оных часто хочется их поделием по голове. Жаль с софтом это затруднительно. Хоть ногами попинать.

> Мне, если честно, почти все равно, что там будет за формат - я хочу API.

Всё придумано уже до нас.

Смешно смотреть как в качестве недостатка gconf указывают ее зависимость от ORBit2 и glib, библиотеки, которые и не больно то к gnome/gtk относятся. К тому же никто не отменял правил статической сборки, достаточно посмотреть на то как это делает Opera. делает статическую сборку и все, есть у тебя qt, нет, ей стало все равно. gconf одназначно, лучше, хотя бы тем что как раз к ней backend по конвертации конфигов написать легче, только вот все конфиги в дерево не запихнешь, из дерева лучше сделать представление кеонфигов, с чем gconf опять лучше справится.

> А-ха. А потом еще и права отберем на завершения любых процессов. И будет нам всем счастье. Виндовое.

Ну, это чуть позже:))

> svu, прекрати позориться. Тебя же дети читают.

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

> На yast посмотри.

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

> Кроме раскладок тебя еще что не устраивает?

Меня как разработчика не устраивает отсутствие того API (enum/get/set), которое я приводил - позволяющего мне обращаться к XF86Config. Меня не устраивает, что такого API нет для 99% файлов в /etc (что раздувает проекты типа linuxconf/webmin за счет всей той smartовости, которую они должны проявлять при парсеньи - и модификации помойки /etc) - а я хочу, чтобы оно было, причем одно на всех.

>Запрещает философия.

Ребята! Какая философия? Что подразумевается под философией у вас? Я вот подразумеваю под философией стиль разработки программ, конфигов и документации. Если есть стандартный стиль описания конфигов, то мне проще проводить интеграцию различных мелких утилиток в единую систему. Кстати, это и есть философия unix, из мелких кирпичиков большие системы.

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

О! Батенька! Да вы тут противоречите себе. Если есть стандарт и есть API для работы с этим стандартом, то нах... скажите мне разработчику думать о конфигах? О синтаксисе, разборке и т.д.? Пусть уж лучше сосредоточится на разработке конечного продукта. А иначе... Вы хоть раз писали серьезные программы? И чтоб программа была с туевой кучей настроек? Да...

>ИМХО: когда люди перестают говорить "функция выполняющая инициализацию", а начинают говорить "конструктор объекта порождающий действующий объект" или "установка соединения" начинает называтся "порождение класса stream между объектом А и объектом Б" кончается здравый смысл и начинается абстрУгирование (мля слово то какое)

А на ваше ИМХО я могу ответить так, я сам не терплю таких выражений. Я всегда придерживаюсь такого мнения, если не можешь другому по человечьи объяснить свою мысль или свое действие, то ты сам не понимаешь что ты делаешь. К сожалению, начальство околоитешное рассуждает наоборот и красивые иностранные непонятные словечки их вводят в состояние нирваны. :( Они считают это признаком крутизны.

> И зачем это всё? Разве требуется при конфигурении клавы лезть в секцию драйвера дисплея? Или от этого сильно зависят фонтпафы?

В том-то и дело, что нет! От этого-то я и зверею - от того, что мне приходится думать о том, что в файле еще что-то есть, что хорошо бы не напортить. Ах, да, конечно, я могу погулять по файлу, поискать секцию клавы - и там покурочить (разумеется, очень аккуратненько обойдясь с комментариями и не попортив их - вдруг там что-то важное). Конечно. С моей-то вселенской ленью - а это же целый курсовик для 2 курса:)

> или используй готовое.

Где? Покажите мне готовое API для доступа на чтение и запись к XF86Config? Простое и понятное...

> А я этого и не предлагал. Да и не понимаю кому может придти в голову писать ГУЯЛКУ на баше.

Будем считать, что мне показалось:) Лениво цитату искать.

> Я так понимаю, эта библиотечка будет только на линухе, и скомпилить совт, использующий ее скажем под бсд будет невозможно...

Неправильно понимаешь. Вообще, написать linux-specific парсер XML - это еще постараться надо.

про GUI без API

> Давай ты гуй "на файлах" сделаешь, без API. А мы посмотрим =)

Вы что, plan9 не видели?

> На все компьютеры админов не хватит. Или по-твоему юзеры должны на каждый чих звать админа?

Я этого не предлагал. К тому же никто не мешает тебе или кому-то ещё написать конфигурялку с существующему файлу. Некоторые УЖЕ написаны.

> IBM уже давно продвигает проект самовосстанавливащих конфигурацию машин.

Это просто продукт, который при хорошем промоушене можно продать или иным способом заработать на этом деньги. Это просто бизнес, а в нём не всё делается так КАК НАДО, там другие цели.

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

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

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

Аналогию, простите, не очень понял:)

> Что сложного в написании ГУЕты к smb.conf?

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

Короче, мой девиз дня: "Хочу высокоуровневые API". А на нижнем уровне - конечно, пусть "все есть файл" - это сколько угодно...

> От этого-то я и зверею - от того, что мне приходится думать о том, что в файле еще что-то есть

Это лишь признак того, что в один файл втиснуто то, что должно лежать в разных файлах. И XML Вам _ничем_ не поможет, если какой-то умник засунет в один ключ разнородную информацию.

> gconf одназначно, лучше,

Тс-с... Сейчас Вас вообще побьют!... Между нами, я тоже считаю архитектуру gconf со сменяемым бекендом более прогрессивной, чем LR - только в ней нет ничего про права доступа, поэтому для system-wide она ышшо не доросла. Но это все между нами. Не будем дразнить общественность:)

> Не слыхал такой, расскажи

Да, типа иностранцы какие-то забурились вглубь России и первый раз УАЗик увидели. Ну и коммент выдали, что только русские не придумают, лишь бы дороги не строить!

> Люблю высокоуровневые интерфейсы. Это плохо?

Хорошо. Но любите Вы, похоже, высокоуровневые костыли.

> Файлы - это нижний уровень, детали реализации

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

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

Пускай этот HIG не лезет дальше всякой гуйни, нечего превращать UNIX в черт знает что...

> Короче, мой девиз дня: "Хочу высокоуровневые API"

А файл -- это и есть высокоуровневый API.

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

С ЭТИМ я спорить не буду. Просто дело в том, что меня ВООБЩЕ не должно колыхать - что в каких файлах лежит. И в файлах ли оно вообще. Я хочу думать и писать код в терминах ConfigEntry.

> И XML Вам _ничем_ не поможет, если какой-то умник засунет в один ключ разнородную информацию.

"Валентина, да мне плевать на Harley-Davidson" (c) "Чиж и К". В смысле - на XML. Это детали реализации backend (просто если бы я реализовывал backend - мне было бы проще его сделать через XML - но пришлось бы с правами доступа помучаться - так что тут еще бабушка надвое)

Дайте мне высокоуровневый API.

про права доступа.

> Тс-с... Сейчас Вас вообще побьют!... Между нами, я тоже считаю архитектуру gconf со сменяемым бекендом более прогрессивной, чем LR - только в ней нет ничего про права доступа

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

> Но любите Вы, похоже, высокоуровневые костыли.

Все, что Выше файла - костыли? Мда... СУБД Вас тоже, наверное, напрягают - такие толстые и могучие костыли... Да, тогда я люблю то, что Вы называете костылями. Абстракции люблю, не зависящие от деталей реализации интерфейсы меня прямо-таки прут...

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

Если что-то может все - значит, реально оно не может ничего:). Да, через файловый API можно все. Только это не отменяет НЕОБХОДИМОСТИ делать высокоуровневые надстройки над ним. Если Вы не согласитесь - я Вас попрошу написать ... почтовый клиент пользуясь только Xlib ("универсальный API для доступа к сервисам X Window System") - без тулкитов (это я еще добрый, а то бы попросил на сокетах:). А также что-нибудь могучее для винюков - только при помощи windows.h.

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

> Пускай этот HIG не лезет дальше всякой гуйни, нечего превращать UNIX в черт знает что...

Вы забываете свои собственные фразы. Вы меня спрашивали про _гуевую_ (!!!) конфигурялку для smb.conf. А где гуй - там хиг:)

> А файл -- это и есть высокоуровневый API.

Это я тоже запишу в свою записную книжку:)

> В ОС должна быть _ОДНА_ система безопасности

Специально для Вас там есть про "бабушку надвое". Не горячитесь так сильно:)

код vs данные

> Бог?:) Двуединый в лице кода и данных:).

Совсем уж примитивный пример:

Integrate[ F[x+y], {x, 0, 1}]

F -- это данные? Или код? Ась?

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

Хэй, браза svu, ты на чём пишешь? Судя по словам SWE по крайней мере интересуешься =). Или по крайней мере банду четырёх усвоил =)

> > А файл -- это и есть высокоуровневый API.

> Это я тоже запишу в свою записную книжку:)

И это запишите... Заодно загляньте сюда:

http://www.qnx.com/developers/docs/momentics621_docs/neutrino/sys_arch/fsys.html

ну и сюда:

http://www.debian.org/ports/hurd/hurd-doc-translator

> Integrate[ F[x+y], {x, 0, 1}] > F -- это данные? Или код? Ась?

А я просто все это вместе назову скриптом.:) И положу 0 и 1 в конфигурацию:)))

Если Вы мне таки хотите доказать, что та модель выделения конфигурации в отдельную подсистему имеет ограничения - я с Вами спорить не буду. Я только вспомню про то, что эта модель применима для бОльшей части (80% или 90%) создающегося ныне софта.

про костыли

> Мда... СУБД Вас тоже, наверное, напрягают - такие толстые и

Именно. Костыли к убогой VFS монолитного ядра.

> А я просто все это вместе назову скриптом.:) И положу 0 и 1 в конфигурацию

Нет, там надо F положить в конфигурацию, 0 и 1 можно считать куском кода. Потому и вопрос F -- это данные или код?