Re: gconf2 на сервере
В сообщении от 2 Июль 2003 20:39 Sergey Spiridonov написал:
> Yuri Nefedov wrote:
> > On Wed, 2 Jul 2003, Sergey V. Spiridonov wrote:
> >>Прокрустово ложе текстовых редакторов? Жконф позволяет использовать всю
> >>мощь целых двух текстовых редакторов: сторонники emacs могут
> >>использовать его для редактирования настроек.
зачем тогда телеге пятое колесо?
> >> Но также жконф упрощает
> >>написание специальных утилит для администрирования.
Вот только я не понмаю смысл написания специальных утилит для
администрирования. самого простого mcedit'а вместе с хорошим ртфмом вполне
хватает для администрирования. с другой стороны я еще ни разу не находил
хорошей и удобной графической конфигурялки, которая бы позволяла добитьс
именно такого резултата, какого хочется. максимум, которого можно добитьс с
их помощью --- выбрать один из предопределенных профилей. "А где находится та
самая галочка..." --- классическая проблема такого интерфейса, на решение
которой может уйли целая неделя или даже больше (я не шучу)
> >
> > А потом, когда таких утилит наберется достаточно много,
> > создадим /bin/etc, поместим их все туда, и назовем это
> > прогрессом :(
>
> Погодите. Я видимо неясно выразился. Это именно то, что происходит
> сейчас, это то что я называл "кошмаром" (возможно слово это излишне
> эмоционально, давайте заменим на "изобретение квадратного колеса"). Есть
> куча утилит, которые могут справиться только с определёнными
> конфигурационными файлами определённых программ (к примеру swat). Есть
> некотрые утилиты, которые пытаются справиться с несколькими
> программами/файлами(к примеру webmin).
если често, то я не понимаю стремления сделать из обезьяны в зоопарке
"грамотного системного администартора" :-D)) есть конечно и полезные утилиты,
но они никда не денутся --- ВАш Gconf будет просто обяза их впитать в себя
>
> У этих программ-конфигураторов и возникают описанные Вами выше проблемы
> - несоответствие версий, форматов и т.д.
проблема несоотвествия версий --- это вообще надуманная проблема, я так
подозреваю, что она пришла зи мира M$ с ее супер реестром, когда установки
одного прилажения напрочь сносят установки другого!!! В нормальных же
условиях, когда "один раз настроил и забыл" такой проблеме просто неоткуда
взяться.
А вот новые (несовместимые) версии gconf'а вполне могут такой геморой Вам
устроить, когда одно приложение будте просить одну версию gconf, а другое ---
другую...
> И это понятно, потому что они
> содержат в себе парсер (бакэнд), который отличается от парсера
> программы, файл которой они пытаются конфигурировать.
>
> Каждая из программ которую они пытаются отконфигурировать, имеет свой
> способ оповещения об изменениях, свой формат конфигурационных файлов,
> свой парсер (и свои ошибки в нём) и т.д.
>
если уж очень нуже дополнительный конфигуратор, который буде работать с
конфигом заданного приложения, можно воспользоваться тем же парсером, который
использует это приложение...
> С помощью идеи заложенной в жконф можно использовать одну(!) стандартную
> утилиту, которая всегда будет соответсвовать версии и формату, потому
> что она не знает, и не должна о формате конфигурационного файла.
В винде такая утилита уже есть --- зовут regedit. лично я считаю, что bash +
rtfm + mc + mcedit намного удобнее. или Вы считаете, что должно быть
диалоговое окно с большим количеством закладок, менюшек, списков, кнопок и
прочей тому подобной хрени? это же каких размеров должен быть этот диалог???
(видели, сколько записей в масдайном реестре???) проблему потерянной галочки
это только усугубит
> Жконф
> инкапсулирует эту информацию. Именно жконф (а точнее системный
> администратор) определяет, какой формат будет использован
а это в свою очередь означает, что соответсвующий код никуда не делся, он
просто перекочевал в gconf...
> (что позволяет
> при желании использовать текстовые конфигурационные файлы, пригодные для
> ручной правки).
не пойму какой тогда смысл в gconf? зачем тогда нужна эта "прокладка"?
> Он также стандартизует способ оповещения,
а это еще что такое?
> вводит возможность удалённого конфигурирования и проч.
удаленное администрирование итак прекрасно выполняется --- ничуть не хуже, чем
локальное
PS есть очень хорошая книжка:
Ален И. Голуб. С & С++. Правила програмирования. --- М.: БИНОМ 1996г. ---
272с.
очень рекомендую почитать, а пока я приведу несколько правил от туда, которые
имеют отношение к теме нашего разговороа:
1) сущьность програмирования: без сюрпризов, минимум сцепления, максимум
согласованности.
2) Подавляйте демонов сложности
2.1) Не решайте проблем, которых не существует
2.2) Решайте конкретную проблему, а не общий случай
4) не путайте легкость в изучении с легкостью в использовании
8) Разлагайте сложные проблемы на задачи меньшего размера
9.1) Используйте для работы соответствующий инструмент
10) Проблема должна быть хорошо продумана перед тем, как она сможет быть
решена,
14) Малое --- это прекрасно. (Болшое == медленное!)
я думаю, что все это достаточно актуально и сегодня
Кстати, qmail на моей машине (четвертый пень 1.7 гига, 512 метров мозгов) в
первый раз грузится секунд 15 а то и больше :-( лет семь назад, когда у меня
был сотый пень с 32 метрами у меня практически все летало...
Еще одно наблюдение
в 1995 на четверке DX2-66 с 8 метрами мозгов сборка ядра занимала около 20
минут. Сейчас на моей машине (см выше) сборка ядра занимает около 4 минут и
это с учетом того, что машина стала круче боле чем в 25 раз !!! вот вам и
прогрес :-(
PSS почему /etc это хорошо
/etc --- это один из краеугольных камней, на которых стоит UNIX. фактически
это опыт, накопленный более чем за тридцать лет его эксплуатации. практически
все программы расчитаны на работу с /etc и для перехода на gconf их все
придется переписать. при этом неизбежно большое количество багов.
API у gconf насколько я понимаю еще не устаялся, потребуется достаточно
большое количество времени, пока станет ясно, что там надо, а что нет.
написание програм, расчитанных на gconf, требует специального подхода. при
разработке уже существующих программ соотвествующие требования естественно не
учитывались, следовательно их переделка совсем не тривиальная задача.
Существует достаточно большое количество приложений конфиги которых нереально
запихнуть в gconf ярчайший пример это senmail, senmail.cf это вообще легенда
UNIX тем не менее алгоритм работы senmail'а очень крепко привязан к этому
конфигу.
Следующий не менее яракий пример --- это emacs там весь конфиг на elisp'е.
кроме того идет большое количество скриптов на bash, perl и тд и тп, которые
либо сами по себе являются конфигами, либо используют другие скрипты в
качестве конфига. конечно можно сделать специальный API для доступа к
содержимому gconf. но конструкции типа include намного проще и надежнее в
этом случае
РЕЗЮМЕ:
Вобщем-то вполне наверно можно заменить /etc на gconf, но это уже будет не
UNIX а какая-то другая система. и вобщем-то подобная система уже есть --- M$
winddows и скажу честно, что уменя ее администрирование вызывает большое
раздражение (по этому я им и не занимаюсь) и я не верю, что вариант gconf
будет намного лучше...
Reply to: