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

Так о том и речь. Так у меня оно один fstab раскидало по тридцати файлам =)

> Если ты не можешь даже парсер кофига написать, то какой же ты начлен кодер?

Я-то могу, но это время можно потратить намного более продуктивно. Скажем, написать нормальную документацию к программе...

> Что же теперь ещё и /etc/registry/users монтировать/шарить отдельно?

ln -s ~foobar/registry /etc/registry/users/foobar

В первой ссылке не нашел ничего интересного. Второе интересно - но меня туда уже посылали:). Да, трансляторы - круто. Только это, во-первых, некое расширение традиционной униховой семантики файловой системы. Во-вторых - тут же народ взвоет, если из заставят править отдельный файлик на каждый ConfigEntry (собственно, они уже это делают по поводу LR). В третьих - я все-таки убежден, что API должно формулироваться в терминах того, для чего оно предназначено (хотя бы ради такой вещи как читаемость кода). Разумеется, реализация config api на файловой системе с трансляторами действительно предельно проста, практически вырождена - но я опять-таки прошу спрятать детали реализации...

На чем только не приходилось...:) SWE - да, интересуюсь, любительски:) Про банду четырех не понял...

Я уже ответил про границы применимости.

Re:

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

Почему не будет? Если создание сайта заскриптовать (а его надо скриптовать при любом более-менее приличном количестве хостов), то вызов webalizer_add_vhost <hostname> никому не повредит. Вы же, напротив, сами себя загоняете в рамки, из которых потом можно будет выбираться исключительно такими вот линукс-регистрями :-).

Да, кстати, webalizer_add_vhost - вполне реальное имя скрипта. написал не далее как неделю назад по просьбе своего знакомца ;-).

ну какая же разница??

> Во-вторых - тут же народ взвоет, если из заставят править отдельный файлик на каждый ConfigEntry

Ну какая разница, то ли записать в gconf/applications/blah значение foo, то ли сделать что-то вроде echo "foo" > /etc/applications/blah ?

Re:

> (извините, тут простые name=valuе файлы становятся неудобными).

Точно-точно :-). Удобными становятся

if CONDITION then ... [else ... ] endif

или хуже того (cond (CONDITION (...)) :-)

> Ну какая разница, то ли записать в gconf/applications/blah значение foo, то ли сделать что-то вроде echo "foo" > /etc/applications/blah ?

На С это будет 3 строки: fopen, fprintf, fclose. А я хочу одну. Более того, хочу иметь ChangeSet с атомарным commit - а для этого придется немножеско повозиться. Более того, хочу иметь нотификацию об изменениях - значит, придется еще и FAM водружать...

Абсолютно согласен. Config4GNU мне не понравился. Ребята, я тоже сразу крикнул ИЗВРАЩЕНЦЫ, но потом почитал и понял, что очень даже ничего, но если действительно буде a-la gconf. И разраничение доступа, и комментарии, и сетевое взаимодействие.

Дуализм получается, навродя "частица-волна". A priori нельзя сказать, является ли нечто кодом или данными. И это не от кривизны рук -- просто жизнь такая...

Re:

:-). И что, остановить не можете?

Ну, дак это, идите, пойдите, набейте морду Лёше Махоткину или Виктору Вислобокову за то что они (оба - дебианщики, кстати) сидят и по мере сил переводят маны.

А вообще, знаете, пи@#еть - не мешки ворочать. Если есть обоснованные претензии по качеству перевода - добро пожаловать в список manpages-ru или где они там тусуются (в любом случае, адреса тех двоих у меня есть, обращайтесь если надо). Если же так просто, кулаки посжимать захотелось - ну да сжимайте себе на здоровье, глядишь, культуристом станете когда-нибудь. Но только молча, без порчи воздуха "русе-" и другими "фекациями".

> На С это будет 3 строки:

Кто-то тут любит высокоуровневый API :)

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

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

Re:

Ну, замечательно, только это будет работать медленее, чем сейчас до тех пор, пока на / не будут в массовом порядке ставить хотя бы рейзер.

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

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

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

Во-во! Вынь, да разжуй и положь! А ты пробовал? Я просто куею, людям требуется целое API, чтобы исправить пару строк в маленьком текстовом файле! Дожили!

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

Так коли не можешь найти, напиши себе этот API! И юзай его хоть для fstab, хоть для smb.conf!

Re:

Здравый смысл.

Сейчас же Вы не жалуетесь на то, что XF пытается искать свои конфиги в /etc/mplayer/mplayer.conf?

> Ну, замечательно, только это будет работать медленее, чем сейчас до тех пор, пока на / не будут в массовом порядке ставить хотя бы рейзер.

Конечно, будет =) Оно и с райзером будет медленней работать. Но не намного. И в целом это достаточно разумный trade-off, не находите?

Хотя конечно посмотреть на результаты конкретных тестов было бы интересно. Скажем, чтение конфига иксов из XF86Config, а потом из LR. И посмотреть, что быстрее, и насколько.

Re:

Прирост в скорости будет на специально созданных для этого FS. На ext2/ext3 будет падение производительности.

> Так коли не можешь найти, напиши себе этот API! И юзай его хоть для fstab, хоть для smb.conf!

Ага. Один API для fstab, другой - для smb.conf...

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

> Прирост в скорости будет на специально созданных для этого FS

Да, я об этом уже упоминал. Если эта штука действительно получит популярность, то можно ожидать появления ФС, специально под нее заточенных (а в принципе кроме эффективной работы с очень большим количеством очень маленьких файлов ничего и не требуется). И вот тут уже можно получить реальный _выигрыш_ в производительности, по сравнению с существующими решениями.

Re:

> а религия запрещает сделать в конфиге так? > gui_background=light > cli_background=dark

Вауч.

Рассказывать, что такое рост по экспоненте? :-)

> Так коли не можешь найти, напиши себе этот API! И юзай его хоть для fstab, хоть для smb.conf!

Так вот LR и хочет им стать. И GConf хочет - и у него даже получается, в своей области. Почему бы мне ими не попользоваться?...

Во подходе с Registry есть как минимум 2 нехороших момента: 1. Вспомните, какой миной замедленного действия оказался реестр в Windows, насколько из-за него все усложнилось, поскольку появилась хреновина, которая все связывает воедино, увеличивая риск глобальных сбоев. От глобальности, кстати, стараются в программировании, как известно, всячески уйти... 2. Unix-подход с /etc и текстовыми конфигами - хорошо прокомментированными, линейными, понятными ЧЕЛОВЕКУ, а не API (что-то мы не читаем книги в виде иерархического дерева), но в то же время легкими для ПРОГРАММНОЙ обработки и (бэк)копирования - дает грамотному администратору полный и гибкий контроль над сервером при локализации ошибок настройки при экспериментировании...

Разнобой файлов в /etc можно преодолеть, сделав front-end, особенно на рабочих станциях: начиная с Webmin и пока фантазия работает... вплоть до админов, не знающих английского и домохозяек (в смысле бухгалтеров и секретарей): виазардов и мастеров наделать... Для подобной шняги реестр приемлем, но только ля ее персонального использования...

Mike Shock

Re:

Брат, а в чем правда? :-)

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

nt19h (*) (03.06.2004 11:06:56)

>> Прирост в скорости будет на специально созданных для этого FS

> Да, я об этом уже упоминал. Если эта штука действительно получит популярность, то можно ожидать появления ФС, специально под нее заточенных (а в принципе кроме эффективной работы с очень большим количеством очень маленьких файлов ничего и не требуется). И вот тут уже можно получить реальный _выигрыш_ в производительности, по сравнению с существующими решениями.

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

Re:

И куда ж я со своим init.el пойду? :-)

Бедный я, несчастный, сирота казанская.

> Так вот LR и хочет им стать. И GConf хочет - и у него даже получается, в своей области. Почему бы мне ими не попользоваться?...

А уж если все это дело объединить... ;|

Re:

:-)

Пропаганда секса и насилия! :-)

> Особенно у лентяев и ... Ничего личного. :-)

Статья "Оскорбление участников дискуссии":))) Да, я ленив. Более того - все самые лучшие программисты из моих знакомых были очень ленивы (и чем круче программист - тем ленивее). И код у них был ленивый-ленивый. Только лень, она умная должна быть...

> Во-во! Вынь, да разжуй и положь! А ты пробовал? Я просто куею, людям требуется целое API, чтобы исправить пару строк в маленьком текстовом файле! Дожили!

Я восхищаюсь! Люди совершенно разучились мыслить абстракциями! Дожили! Вспоминается один мой бывший начальник, который на какой-то концептуальный вопрос ответил радостно: "Да, конечно, и мы отобразим это на экране синеньким..."

уперлись вы в этот xf86config....

Млин! Я что-то не въехал... Что все зацепились за этот гребанный конфиг ? Или уже появились карточки и мониторы которые в процессе работы самомодифицируются и приходится по три раза на дню переколбасивать конфиг иксов ? Или ради того чтобы вляпать хкбрулез уже надо ставить библиотечку распарсивания конфига ? Ну типа юзабилити и т.д... а что xf86conf и его гуевого собрата уже отменили ?

>микрософтовских офисах прячуться пункты меню которые ты не юзаешь?
зае..ля я уже с этой фичей в WinXP - не знаю как отключить !!!!

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

В данном случае оно не столько связывает воедино, сколько устанавливает некий стандарт. Разницу замечаешь?

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

> Unix-подход с /etc и текстовыми конфигами - хорошо прокомментированными, линейными, понятными ЧЕЛОВЕКУ, а не API (что-то мы не читаем книги в виде иерархического дерева), но в то же время легкими для ПРОГРАММНОЙ обработки и (бэк)копирования - дает грамотному администратору полный и гибкий контроль над сервером при локализации ошибок настройки при экспериментировании...

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

> И куда ж я со своим init.el пойду? :-)

Нет, если вы настаиваете, мы и его в LR запихнем. Одним ключом =) И vimrc туда же - ну это мы выше уже обсуждали.

Так что, видите, не все для вас потеряно ;)

int19h (*) (03.06.2004 11:21:15)

>> Unix-подход с /etc и текстовыми конфигами - хорошо прокомментированными, линейными, понятными ЧЕЛОВЕКУ, а не API (что-то мы не читаем книги в виде иерархического дерева), но в то же время легкими для ПРОГРАММНОЙ обработки и (бэк)копирования - дает грамотному администратору полный и гибкий контроль над сервером при локализации ошибок настройки при экспериментировании...

> Мне этот пассаж почему-то напомнил типовые фразы из рекламных проспектов фирм-производителей софта. Прочитаешь - и вроде толком так и не понял, что тут действительно хорошего... но звучит приятно ;)

Ты не админ или дурак?

Re:

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

Re:

Где получаем? Нет, я серьезно, если его еще где-нибудь раздают в _приличном_ виде - я первый в очереди :-).

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

Я не админ. Еще вопросы?

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

Неуж-то Хаскель популярность набирает? :-))

>Люди совершенно разучились мыслить абстракциями

Не, просто абстракции другие. Не "параметр" а "набор параметров". Причем наборы бывают существенно разные, поэтому универсальный интерфейс - текстовый редактор :-)

Re:

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

Re:

Вот как раз с иерархичностью в xrdb никаких проблем.

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

Да, но при сериализации объектов, вы все-таки не храните их код, а только данные?

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

> Причем наборы бывают существенно разные, поэтому универсальный интерфейс - текстовый редактор :-)

Конечно. И среда выполнения этого редактора бывает разной, поэтому универсальный редактор - ed. :)

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

А если он декларативный, тогда зачем делать его на скриптах? =)

> Кстати, код - он характерен для класса, а не для объекта.

Слыхал я что-то про языки, где это не совсем так. Врали, наверное:)

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

>Не разводи дезинформацию, Дурень. stupid - прилагательное и относится оно к it, а вовсе не обращение. :)

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

> Слыхал я что-то про языки, где это не совсем так. Врали, наверное:)

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

>В данном случае оно не столько связывает воедино, сколько устанавливает некий стандарт. Разницу замечаешь?

Об разнице и речь. Стандарт никудышный...

>Мне этот пассаж почему-то напомнил типовые фразы из рекламных проспектов фирм-производителей софта. Прочитаешь - и вроде толком так и не понял, что тут действительно хорошего... но звучит приятно ;)

Ну, извиняйте, что на литературном и без матюков...

>А в виндах реестр превратился в помойку потому, что активно использовали не по назначению (в том числе и сам майкрософт),

Все по закону Мерфи: если что-то может стать помойкой, то станет ей!

Mike Shock

int19h (*) (03.06.2004 11:31:14)

> Я не админ. Еще вопросы?

1. Программер?
2. Как ты себе представляешь систему безопасности этого "реестра"?
3. Как ты себе представляешь систему удалённого (по слабым каналам) изменения настроек?
4. Что нужно будет изменить в Linux для нормального функционирования "реестра"?
5. Какова будет система инициализации?
6. Какова будет система доступа программ a la chroot (jail, etc) к "реестру"?
7. и т.д. и т.п.

Если не программер, можешь не отвечать.

> Ага. Один API для fstab, другой - для smb.conf...

Зачем разный? Чем так сильно fstab отличается от smb.conf? Есть параметр, есть значение. Ну, разве что в первом = не стоит. Во проблема!

> это надо чуть ли не к каждой новой софтине бэкенд писать, под ее конфиги.

Зачем? Совершенно нет!

Я догадываюсь что ВАМ нужно.

1. Прога (тот самый API) выцепляющая по запросу параметр, открывающая этот параметр на r или rw. Ну и всякие там статусы возврата.
2. Эта прога пользуется своим файлом конфигурации. Поскольку нет стандарта на то где что лежит, то имена конфиг и их расположение она держит там.
3. Недурно будет, да и несложно сделать так, чтобы эта прога при первом запуске прочёсывала /etc и сама создавала этот файл, но лучше бы дистростроители подсуетились.
4. Легко в комментариях конфигурационных файлов ввести дополнительные параметры для этого API, а ещё лучше вынести всё это в отдельные файлы типа fstab.aconf smb.aconf (api conf).

smb.aconf >>

netbios name {
name 'Имя машины в сети'
decription 'траляля'
....
}

5. Да много чего можно придумать!

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

ps Идея не блестящая, но легко реализуема и не требует жертвоприношений.