Re: gconf2 на сервере
Victor B. Wagner wrote:
[snip]
Это почти не аргумент. Если ты строишь информационную систему с нуля,
то ты просто не будешь тратить деньги на CPU/винты на каждое рабочее
место.
В этой схеме есть свои преимущества и недостатки. Это просто одна из
возможных конфигураций.
Ситуации, когда такая схема неоптимальна, бывают, но ты не там их ищешь.
Вполне достаточно того, что такие ситуации встречаются и не редко.
Другой: если у меня иерархия серверов, и часть настроек хранится на
более высоком уровне (например сервер предприятия - сервер отдела), всё
равно нужна синхронизация.
Перестань мыслить в категориях клиент/сервер и тебе станет гораздо
лучше.
Хорошо. Возможно готовые решения есть и они работают. Просто я о них в
силу ограниченности своего кругозора не знаю. Если ты знаешь, то будет
лучше если ты напишешь о них, иначе я не понимаю того что ты написал ниже:
То?
Все это g выбросить нафиг, и искать решения в другой области - NIS+,
LDAP, rsync, rdist.
rsync и rdist? И что мне предлагают они? Синхронизацию файлов?
NIS+ специализированная, заточена под определённые задачи, которые
успешно решает и ничего больше, к тем задачам, которые адресует жконф,
нис+ никакого отношения не имеет.
LDAP тоже, но это скорее база данных. С таким же успехом можно написать
mysql вместо LDAP, например. Это один из способов хранения и извлечения
данных, один из форматов. Но этого мало, я уже писал об этом раньше.
Некоторые сложные в настройке приложения действительно используют свой,
иногда очень сложный язык. Некоторые берут уже существующий язык и
используют его для настройки. Я не буду на них останавливаться, так как
для каждого нужен свой отдельный подход, да не так уж их и много.
А в остальных случаях все вполне укладывается в концепцию иерархической
базы данных с наследованием, т.е. xrdb.
Я повторюсь возможно, но дело совсем *не* в способе хранения, которыми
жконф в принципе может и не заниматься, этим может заниматься LDAP,
mysql, xrdb и т.д.
[snip]
--
Best regards, Sergey Spiridonov
Reply to: