rtzra,
Ниже объясню, в чем я не согласен, или считаю что стоит уточнить. В остальном согласен с вами.
1. Еще плюсы текстовых конфигов:
Легкий бакап и перенос конфига.
Нет привязки к конкретной системе конфигурации.
Возможность скриптом создать нужный конфиг. (Думаю нужен пример.
У меня iptables переконфигурируется скриптом, который получает обновления адресов внутренней сети провайдера и еще кой-чего получает.)
Возможность быстрой передачи. (Да, не все конфиги шаблонны, но большенством пользователей Linux моего крупного провайдера пользуются одним конфигом iptables из местной вики. Меня иногда просят написать конфиг к чему-нибудь и я могу скинуть его просто на мыльник.)
2. Еще плюсы GUI:
Гораздо меньше возможности ошибки или опечатки.
Возможность быстро сконструировать пример конфига для дальнейшего подробного разбирательства.
3. Минусы текстового конфига:
Многие пользователи не комментируют то, что меняют и потом даже сами не могут понять, где и что настроено.
Много различных синтаксисов и их необходимо соблюдать.
Трудность сохранения измененного программой конфига в том виде, в котором пользователь его сделал, а следствие пользователю опять разбираться. (сохронить форматирование, инклуды, комментарии В НУЖНЫХ местах и прочее)
4. Минусы GUI
Опять проблема 3.4
Трудность своевременной реализации всех изменений в программе.
Трудность реализации сложных конфигов. (для интереса поставил kmyfirewall, я так-то легко правлю конфиги iptables и не особо задумываюсь, при создании правил, но когда я ЭТО увидел, то понял, что я лучше дальше строчки буду придумывать, чем разберусь в этом монстре, который съест, в это время, мой мозг
)
По поводу МС.
Серверный сегмент в энтерпрайзе они и так слили полностью. Их продуктами пользуются небольшие конторы, которым хватит низкооплачиваемого админа, который сможет поддерживать виндоус в рабочем состоянии. В серьезных проектах Их не используют. Тут и надежность, и медленность настройки, через графику. Представьте GUI для ПОЛНОЙ точной настройки апача? Мне вот сложно. Там бедет столько всяких "но", что в кнопках и галках захлебнешся, а в тексте можно быстро разобраться, а про скорость правки просто молчу. Тут и возможность удаленной настройки. Сейчас вообще пошла гиганская мода на виртуальные хостинги. И дешево и полностью подконтрольная машина. Попробуй туда виндоус поставь?
А теперь последний момент, из-за которого виндоус на сто шагов позади всех.
Это инертность и отсутствие двойного контроля.
IT мир развивается уже с огромной скоростью. Новые аппаратные платформы и решения выходят, чуть-ли не каждые пол года - год. И скорость все увеличивается!
МС уже не справляется с этой скоростью. Отстает. Но ладно МС поздно, например, выпустила поддержку 64 камней. Фиг с ним. Их проблема в том, что они НИЧЕГО не контролируют. Много сейчас софта переписано на 64? Тут и оно. Это в Linux сделана гениальная вещь. Вендоры основных дистрибутивов контролируют ПРАКТИЧЕСКИ ВСЕХ разработчиков и могут от них требовать! А разработчики контролируют вендоров, т.к. без их помощи в поддержке их программ в дистрибутиве - дистрибутив загнется! И, тут пользователи виндоус подумают, что я съязвил!
Собрались RH Debian Gentoo Slackware, Novel, Canonical подумали и сказали: "А давайте сделаем у нас полную поддержку 64 архитертуры?!". И программеры с мэйнтейнерами подорвались ее реализоовать! Думаете прикол? А ведь правда подорвались!
Вот поэтому Linux и впереди на 100 шагов. То что KDE там сейчас глючит - это мелочи. Допилят ее. И софт можно написать. А вот взять под контроль всех девелоперов под свою платформу МС уже не сможет, и заменить их всех не сможет. А значит так и будет увеличивать технологическое отстование. Например ПЕРВЫЕ В МИРЕ сделали PowersHELL, которым можно без графики сервера настраивать! Они сделали шел-конфигуратор. Молодцы! Такие-же инертные вин-онили админчики будут этим пользоваться? Ох сомневаюсь... Лет пять - десять пройдет прежде чем МС их отучит от окошек, а отучив админы посмотрят, как приятно и давно это сделано у других, а они с МС в придачу опять опаздали и пользовались недоделкой, которую заново изобрели. И наконец осознали, что им не завидуют, над ними ПРАВДА СМЕЮТСЯ! Грустно всетаки за некоторых коллег.
Возвращаясь к конфигам.
Фактически, если не пользоваться конфигом, то где хранить? В БД? И в чем тут плюс? В скорости? Это фигня. Конфиг - это не место конфигурирования, это и есть настройка программы, просто понятная не только программе. Надо это понять. А вопрос только в том, как именно этот настроечный файл редактировать. Вручную, конфигуратором, встроенным в саму программу визардом...
Вы пытаетесь выбрать, что лучше. Это не тот подход. Конфиг при любом раскладе может быть текстовым и читаемым. Весь вопрос в том, как и кому удобнее его редактировать. И как эффективнее. Сейчас мы имеем отсутствие этого выбора. Только ручное редактирование. Я же хочу попытаться предоставить выбор пользователю. И я абсолютно не имею ввиду полный перенос типа конфигурации в графику, тем более всех программ. Я предлагаю сделать ВОЗМОЖНОСТЬ GUI-конфигурации основных возможностей для программ, которые могут понадобиться новичку. Это программы, в большенстве своем - общего назначения. И у меня и в мыслях нет делать, например такой конфигуратор для sendmail. Это не программа для "домохозяйки" и конфигурация ее в графике только запутает все и усложнит.
Я бы хотел видеть программу, которая создает на основе пользовательского ввода в окошки и расстановку галочек конфиг. Реализует она только основные возможности. Что большенству и надо. Тот-же squid. Что сложного сделать в окошках настройку обычного или прозрачного прокси на интерфейс? Там все типовое.И генерация такого конфига - легкая задача. Но не надо в этот GUI засоовать таки возможности, как squid + LDAP + Mysql + "еще сто-одна примочка с отправкой sms на мобильник, когда дома порнуху качают"..Это уже не тривиальные задачи и для этого НАДО сидеть и лохмати... эээ... лопатить конфиги.
Тема: Предложение по разработке графического конфигуратора (Прочитано 4608 раз)
