> > 2) локализация комментариев - курам на смех!!

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

Конфиг lynx-а для кого приводился? :)

2bizanine (*) (03.06.2004 18:00:35)
ок, так все-таки на... зачем этот реестр надобен? Настройки - один раз настроил и забыл, тем более fstab %-) А челу из HAL (IBM+1 %-)) просто бабуляников за идею захотелось, а Вы и подхватили.
З.Ы. "Машина должна работать, человек - думать" - чей девиз? :-)

2anonymous (*) (03.06.2004 18:16:37)
упс, ашипка вышла, HAL=IBM-1 %-)

>А гляньте-ка в /etc ИМХО всё не так уж и страшно.

Мне каждый день приходится там ковыряться(ну, не каждый, но часто). Оно конечно не страшно, но некрасиво. Отсутствие "системого подхода" видно за каталог:-). А в subj-е IMO некрасив только формат значения (нельзя сказать var=`cat /registry/.../key`) но cat в примере ничем не лучше какого нибудь `rg get registry/.../key`, потому это несущественно.

позвонил знакомому физику, слакваристу - он против. физики - против регистра!!!

> А в subj-е IMO некрасив только формат значения

Ничего себе "только". "В автомобиле не хватает 'только' колес". :)

> Останутся скрипты в /etc/rc.d и худенький-худенький /etc/sysconfig
> - чтобы задавать параметы для обращения к реестру. Но это все
> мечты...

Открой для себя /etc/rc.conf in FreeBSD и прослезись...

Для дестопа реестр нужен. А то ставит юзер систему, ставит KDE, а потом ещет как сеть настроить. Не дело юзера в /etc посылать. А программам (напр. KDE) не дело текстовые файлы парсить. Зачем на десктопе хранить имя компа в hostname и samba.conf (NetBIOS name)?

Ну а серверам, "сам бог велел" не иметь реестра. Хотя бы для прозрачности конфигов (дабы не искать там закладки).

Мы тоже физики Ж), я не думаю что "физики-слакваристы" (читать ядерщики?) были столь категоричны по поводу реестра.

> Для дестопа реестр нужен. А то ставит юзер систему, ставит KDE, а потом ещет как сеть настроить. Не дело юзера в /etc посылать

Не дело юзерам систему ставить, да сеть настраивать. Само оно должно.

>Не дело юзерам систему ставить, да сеть настраивать. Само оно должно.

Может в каждый дом по админу? Чтоб систему ставил, сеть настраивал, фотоаппараты цифровые, сканеры.... ?? Бред!

> Может в каждый дом по админу? Чтоб систему ставил, сеть настраивал, фотоаппараты цифровые, сканеры.... ?? Бред!

Я и говорю: юзер систему настроить не может, админа в каждый дом не посадишь. Само оно должно - как холодильник.

2anonymous (*) (03.06.2004 18:30:46)
>Для дестопа реестр нужен. А то ставит юзер систему, ставит KDE, а потом ещет как сеть настроить.
Для десктопа нужно готовое решение, а не реестр. А насчет сети, так юзеры пугаются слов "с какой ошибкой у вас почта не принимается?" - в ответ на "у меня не работает интернет".

>Не дело юзера в /etc посылать.
Точно, его надо посылать за пределы операционной системы :-)

>А программам (напр. KDE) не дело текстовые файлы парсить. Зачем на десктопе хранить имя компа в hostname и samba.conf (NetBIOS name)?
А Вы это программистам КДЕ расскажите, где им настройки хранить.
Про lmhosts в курсе? А про то, что на самом деле NetBIOS name?

Людиии !!! Ну не дебилы ведь не один десяток лет все это делали.
Во всех дистрах(почти) местоположение конфигов стандартно.
Кто делат иначе - без лишней скромности макать мордой в собственное дерьмо.
И конфигурялок всяких гуевых куча. Яст,Дракконф,линуксконф.... Ну там контролцентр(для КДЕ).
Не все конечно зашибись,но дорогой идем верной (ИМХО).

ЗЫ Мож кто пробовал дрейкутили в фдеоре или другом ? Работать может ? :-))
Яст ,скорее всего,кроме как в Сусе нигде работать не будет.

ЗЗЫ Я понимаю,что заняться совсеи нечем,но это уже случай клинический...

ЗЗЗЫ Мощный флейм. (Каникулы начались ? :)))

> Открой для себя /etc/rc.conf in FreeBSD и прослезись...

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

Мда, народ, death toll на 800+ мессаг and counting - это ЛОР надолго запомнит...:))))

> Затем мне захочется чтобы a=$v, а b,c,d,e = $w, так что его тоже загружать? И в программе предусматривать поддержку этих _вспомогательных_ значений?

Таким образом Вы просто меняете скритп, в самом начале загружаете 100 в $v и используете как хотите.

> Один.

Если значение использует всего один скрипт, никто сторонний его менять не собирается, то использование LR в данном случае будет не только полезно но даже и вредно. Зачем мусорить реестр ?

> А как он его найдет? Нет, он честно будет менять значения a,b,c,d,... Он просто изменит 100 на 200 в реестре.

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

Просто там перечисленны проблемы которые пытается решить LR :)

> Поймите, что это частное мнение (один человек - один голос :)) разработчика из другой среды. Суждение щуки о необходимости постройки моста. :)

Просто он пытается решить проблемы, он не один пытается это сделать, есть аналогичные проекты. Ссылки были в треде.

> Таким образом Вы просто меняете скритп, в самом начале загружаете 100 в $v и используете как хотите.

Тогда поменяется и 'a' - а этого я не хотел.

> Если значение использует всего один скрипт, никто сторонний его менять не собирается, то использование LR в данном случае будет не только полезно но даже и вредно. Зачем мусорить реестр ?

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

> Просто там перечисленны проблемы которые пытается решить LR :)

Нет, там перечислено то, что данный конкретный человек считает проблемами.

> Просто он пытается решить проблемы,

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

> он не один пытается это сделать, есть аналогичные проекты. Ссылки были в треде.

Много чего есть. Это не повод хвать всякую гадость.

Если у Вас какая-то переменная (b,d) __жестко__ выводима из v - тогда Вы либо в init.script ее инициализируете (а саму переменную вообще нечего в конфиг запихивать - в этом нет смысла), либо прямо в коде программы - это не важно. Если она "иногда" связана с v - тогда Вы либо извольте хитрую логику запихать в тот же init.script, либо просто считайте ее независимой конфигурационной переменной. Потому как в данный момент Ваша позиция относительно a совершенно не ясна - то ли она связана с v, то ли нет.

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

> Если у Вас какая-то переменная (b,d) __жестко__ выводима из v - тогда Вы либо в init.script ее инициализируете (а саму переменную вообще нечего в конфиг запихивать - в этом нет смысла), либо прямо в коде программы - это не важно. Если она "иногда" связана с v - тогда Вы либо извольте хитрую логику запихать в тот же init.script, либо просто считайте ее независимой конфигурационной переменной. Потому как в данный момент Ваша позиция относительно a совершенно не ясна - то ли она связана с v, то ли нет

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

Выгоды: программа _тупо_ читает значения пременных, не заморачиваясь над тем как они связаны и как _мне_ удобнее читать-редактировать конфиг.

> Тогда поменяется и 'a' - а этого я не хотел.

Сделайте так: v=<значение из LR> a=<другоe или тоже самое значение из LR или 100> ....

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

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

Я запутался :) Не понимаю в чем вопрос :) Навероное уже голова тормозит. Можно поподробнее с примером что в конфиге, что в коде скрипта и где трабл если конфиг поменять на реестр. Мы вроде бы начинали от того, что нельзя тот пример запихнуть в реестр (самый первый, где v=100 \n a=$v \n ... ). Я сказал что это скрипт а пихать надо 100.

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

И этот человек пишет LR который решает проблемы, которые он считает проблемами. Я считал что это должно являтся ответом на вопрос, зачем нужен LR.

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

ИМХО, было бы неплохо если бы он сделал это, и решил _свои_ проблемы :) Это бы решило некоторые проблемы которые возникли перед разработчиками linuxconf, драйверов к иксам, ну и т.д.

> Много чего есть. Это не повод хвать всякую гадость.

Ну да, в Linux-е, ИМХО, гадость не приживется :) На то он и Linux.

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

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

> Выгоды: программа _тупо_ читает значения пременных, не заморачиваясь над тем как они связаны и как _мне_ удобнее читать-редактировать конфиг.

Я вроде бы понял, тут или переписать немного, или не использовать LR :) Это получается отдельный случай.

По конфигу см. мой ответ svu.

> И этот человек пишет LR который решает проблемы, которые он считает проблемами. Я считал что это должно являтся ответом на вопрос, зачем нужен LR.

Это дает ответ на вопрос, зачем _ему_ нужен LR. Вопрос о полезности LR "вообще" остается открытым.

> ИМХО, было бы неплохо если бы он сделал это, и решил _свои_ проблемы :) Это бы решило некоторые проблемы которые возникли перед разработчиками linuxconf, драйверов к иксам, ну и т.д.

И прибавило бы проблем (настоящих) всем остальным :)

> Ну да, в Linux-е, ИМХО, гадость не приживется :) На то он и Linux.

Почему? Верующих много.

тривиальный пример

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

По конфигу см. мой ответ svu.

>Я уже ответил :)

Дальше сплошное ИМХО :)

> Это дает ответ на вопрос, зачем _ему_ нужен LR. Вопрос о полезности LR "вообще" остается открытым.

ответ в след ответе :)

> И прибавило бы проблем (настоящих) всем остальным :)

ИМХО, решает больше :)

> Почему? Верующих много.

ИМХО, Путь Линукса определяет большинство, если большинству нравится KDE то он и развивается, хоть для других он и говно. Есстественный отбор :) Если что-то трудно обрабатывается или вызывает проблемы, то его пытаются заменить.

А как насчет security ? Или регистр этот у каждого свой будет ? а системный типа в етк положат. А потом баги ловить всю оставшуюся жизнь будут. Не надо линух в винду превращать !

> У меня пара десятков параметров у которых _почти_ всегда одинаковые значения

Что значит "почти всегда" для конфигурационных переменных? Для начала - Вы в данном случае выступаете как админ или как разработчик?

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

Если Вы разработчик - Вы все-таки должны хорошенько подумать - связаны ли между собой эти переменные или нет. Если в 99% случаев b и d жестко завязаны на v - можете ввести доп. соглашение (например, если они не установлены - использовать значение v).

Так что я не вижу никакой проблемы. Разумеется, проблемы возникнут, если запретить скрипты вообще. Только кто же собирается это делать?

> Выгоды: программа _тупо_ читает значения пременных, не заморачиваясь над тем как они связаны и как _мне_ удобнее читать-редактировать конфиг.

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

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

Трудно что-либо возразить :) Вот только естественный отбор - это у зверюшек, человек должен быть разумным :)

> Что значит "почти всегда" для конфигурационных переменных? Для начала - Вы в данном случае выступаете как админ или как разработчик?

Как анонимус с ЛОРа.

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

А где выгоды от применения реестра? Так это уже есть и естественным способом. Реестр же лишь прибавит геморроя.

> Если Вы разработчик - Вы все-таки должны хорошенько подумать - связаны ли между собой эти переменные или нет. Если в 99% случаев b и d жестко завязаны на v - можете ввести доп. соглашение (например, если они не установлены - использовать значение v).

Нет уж. Каждый должен заниматься своим делом и решать свою задачу. Разработчик не гадалка и не может предусмотреть всё. Попытки предусмотреть всё сами знаете чем заканчиваются.

> Так что я не вижу никакой проблемы. Разумеется, проблемы возникнут, если запретить скрипты вообще. Только кто же собирается это делать?

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

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

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

> Какие еще требования появятся через пару сотен мессаг? Вы чувствуете, как во весь свой исполинский рост встает перед нами образ админа-эникейщика?

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

> Как анонимус с ЛОРа.

А это какая позиция по отношению к софту?:) Сверху, сбоку?

> А где выгоды от применения реестра? Так это уже есть и естественным способом. Реестр же лишь прибавит геморроя.

Реестр и скрипты ОРТОГОНАЛЬНЫ. Они решают разные задачи. Кто-нибудь в этом астрономическом треде сказал, что реестр вытеснит скрипты???

> Каждый должен заниматься своим делом и решать свою задачу. Разработчик не гадалка и не может предусмотреть всё. Попытки предусмотреть всё сами знаете чем заканчиваются.

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

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

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

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

Ключи реестра берутся в справочнике. Если конфигурялки действительно автоматические - человек им не нужен вообще. А если автоматизированные - конечно, нужен. Человек, который понимает такие вещи как routing, arp, netbios, nat, .... - только при чем же тут программирование?

> Как представлю себе: выйдешь на улицу, а там полно админов-эникейщиков, знающих английский и десятки скриптовых языков. Почему меня это не пугает?

Потому что это нереально. Человечеству не удалось создать армию квалифицированных админов - и не удастся. И создатели ПО должны считаться с этим фактом.

И еще, напоследок... удобство разработчикам в виде облегчения написания (в виде Borland компонент, ODBC, MFC, etc) в конечном итоге выливается в геморрой для админов (или пользователей, если это домашний комп). Ради Бога, не мешайте мух с котлетами и коней с людьми. Одна небезызвестная фирма уже попыталась, обеспечила туёву хучу рабочих мест для эникеев, типаадминов и повер юзеров. Неужели ненаглядный пример? Зачем превращать _собственные_ трудности в проблемы для всех остальных?
З.Ы. Вспомнилось: обучаем смертельным ударам за 24 часа. В итоге куча переломов обучающихся, неправильное понимание сущности боя и пальцы в растопырку до первого _реального_ уличного поединка.
З.З.Ы. Сорри за оффтоп, занадоело.

> Ключи реестра берутся в справочнике. Если конфигурялки действительно автоматические - человек им не нужен вообще.

Догично, но тогда можно считать что конфига не существует вообще.

> А если автоматизированные - конечно, нужен. Человек, который понимает такие вещи как routing, arp, netbios, nat, .... - только при чем же тут программирование

Чтобы предоставить ему удобный язык для выражения и записи его мыслЕй. А не xml и не key-value.

> Реестр и скрипты ОРТОГОНАЛЬНЫ. Они решают разные задачи. Кто-нибудь в этом астрономическом треде сказал, что реестр вытеснит скрипты???

Реестр ИЗЛИШЕН. Раз между конфигурационными файлами и скриптами нет никакой разницы и реестр не вытеснит скрипты - так куда же пристроить реестр?

> Может и обязан. Разработчик, который не предусмотрел некий use case - не сможет сделать так, чтобы софтина его корректно обрабатывала.

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

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

Это внутренние проблемы кобола. Если бы это можно было настроить из конфига ... :)

> Раз между конфигурационными файлами и скриптами нет никакой разницы

Кто это сказал? Это разные вещи. У меня было слово "ОРТОГОНАЛЬНЫ".

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

Но он справился (или не справился?) угадать все опции командной строки, нужные пользователям cat. Мне кажется, моя аналогия точнее. Все use cases - это не все возможные случаи. Это все возможные типы случаев использования ПО.

> Это внутренние проблемы кобола. Если бы это можно было настроить из конфига ... :)

Это пример того, как неудачное предсказание разработчика вышло боком. И мораль отсюда - предсказывать надо, причем точнее...:)

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

Ирония в том, что хороших админов трудно найти - они в дефиците и их на всех не хватает.

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

Это решение объясняется ограниченностью аппаратных ресурсов в то время. Кстати, больших траблов из-за этого не возникло :-)

2anonymous (*) (03.06.2004 20:21:46)
>Ирония в том, что хороших админов трудно найти - они в дефиците и их на всех не хватает.
Хорошего всегда не хватает, зато много водоплавающего :-)

> Кто это сказал? Это разные вещи. У меня было слово "ОРТОГОНАЛЬНЫ"

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

> Но он справился (или не справился?) угадать все опции командной строки, нужные пользователям cat. Мне кажется, моя аналогия точнее. Все use cases - это не все возможные случаи. Это все возможные типы случаев использования ПО.

Не совсем. Много лишних и нет нужных :)

> Это пример того, как неудачное предсказание разработчика вышло боком. И мораль отсюда - предсказывать надо, причем точнее...:)

Мораль другая. Разработчик всегда ошибется впредсказания и поэтому нужно выносить все что можно в пользовательские настройки. Пользователю виднее в каком году он будет работать :)

> Это решение объясняется ограниченностью аппаратных ресурсов в то время. Кстати, больших траблов из-за этого не возникло :-)

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

> Еще раз, медленнее: мне рассказывать вам, что такое 2^n и почему именно с этой скоростью вам придется плодить конфигурационные параметры, если режимов работы много, и они могут сочетаться в проивзольном порядке?

что такое 2**n - не надо. лучше расскажи почему число параметров будет расти именно во такой кривой. кстати, ничего не мешает конфиг сделать иерархическим и после того все будет совсем кашерно. и расскажи почему в твоем случае сложность инитскрипта будет меньшей. последнее меня больше всего интересует. НЕ ВЕРЮ что можно получить качественно различающиеся результаты в зависимости от того, где инициализировать переменные с возможностью пойти несколькими путями.

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

> Так вот этот скрипт - он и будет конфигом.

Это решение годится ТОЛЬКО для ручного администрирования - автоматизировать его хоть как-то практически не возможно. Оно плохо масштабируемо без специальных ухищрений.

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

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

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

> Это решение годится ТОЛЬКО для ручного администрирования - автоматизировать его хоть как-то практически не возможно. Оно плохо масштабируемо без специальных ухищрений.

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

> Уважаемый, вы поймите, что кроме суперскалярности (про которую тоже нужно еще помнить), есть еще такие "банальные вещи" как конвейеры c read-ahead'ом, кэши данных и т.п., за которыми головой уже особенно не уследишь. И одна и та же инструкция будет выполняться разное время в зависимости от того, что там делалось до, и что будет делаться _после_, как это не обидно. Я вам точно говорю, я сам по этим граблям бегал

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

> Это решение годится ТОЛЬКО для ручного администрирования - автоматизировать его хоть как-то практически не возможно.

Так его и не нужно масштабировать. Оно и так достаточно удобно и прозрачно.

> Оно плохо масштабируемо без специальных ухищрений.

Когда я слышу слово "масштабируемость" я хватаюсь за пистолет. :) Решать всегда надо частный конкретный случай - "общие" решения неработоспособны.

Изнвиняюсь, но следует читать "Так его и не нужно автоматизировать".

> Так его и не нужно масштабировать. Оно и так достаточно удобно и прозрачно.

Не нужно, конечно. Количество сервисов на предприятии вряд ли когда-нибудь превзойдет десяток. Да и файрволлов больше двух тоже не будет. А файлсервер вообще нужен только один - мы туда побольше дисков понапихаем. Угу...

> Когда я слышу слово "масштабируемость" я хватаюсь за пистолет. :) Решать всегда надо частный конкретный случай - "общие" решения неработоспособны.

Большое количество частных решений приводит к большому общему бардаку.

все это справедливо, когда конфигурация - это просто набор пар ключ-значение. Если же конфигурация хорошо продумана, то все не так страшно. Посмотрите на тот же sawfish :)

У "Скриптовиков" и "функциональщиков" тоже есть своя правда, причем подкрепленная практикой.

Тут как в анекдоте:

- Ты прав и ты тоже прав - Но как они могут быть правы одновременно? - ... И ты тоже прав, сын мой.