> Это не так. На хорошей практике всегда должны проводится Насчет всегда - спорный вопрос. Верите в серебряные пули? Могу вас расстроить: куча отличных с теоретической точки зрения софтин и железяк ... успешно вымерли за ненадобностью.
> теоритические
FAIL. На месте теорЕтиков я бы на вас обиделся ;).
> изыскания.
Изыскания и архитекура - это хорошо. Только в случае софта хорошо, если не становится самоцелью а ориентировано на практический результат. Типичная проблема излишне академических продуктов - они увлекаются в изысканиях погоней за красивой архитектурой настолько, что их продукт получается хорошим только с теоретической точки зрения. А с практической - иногда и полный отстой случается. Потому что то что красиво в теории совсем не обязано хорошо работать в реальном мире с его неидеальностями.
> Это видно даже в свете данной новости.
Я не думаю что аццель является идеалом теоретически правильного построения систем. Зато он очень недурен как инженерное решение.
> Да представленное решение решает текущие задачи
Ну а если решение не решает текущие задачи - так оно никому не нужным оказывается.
> но, благодаря своей монолитности не допускает быстрой интеграции нового функционала.
Зато когда вопрос состоит в том что или купить в 2 раза больше серверов (или купить в 2 раза более дорогой и мощный хомяковый роутер) - все почему-то внезапно выбирают решение которое им позволяет сэкономить в 2 раза. Наверное как раз потому что у них есть задачи которые надо решать и ограниченные суммы бабла на их решение. А переплачивать в два раза за решение всех возможных подтипов задач - как-то никому и не вперлось, если этих типов задач на горизонте нет и не предвидится.
> Тот же netgraph в этом плане значительно гибче, из этого конструктора легко
> собирается все что угодно и в любых сочетаниях.
Наверное, теоретикам трудно понять, но зачастую - нахрен не надо решать все возможныее задачи вообще. А достаточно решить те которые стоят перед вами или которые могут появиться в обозримой перспективе. Ну а слишком общее решение - как правило труднее реализуется и хуже по параметрам. Можно посмотреть на всякие там софтапдейты и журналы у бсдунов. Ну да, упирались, реализуя в общем виде. А на практике - есть ufs, для которого это мертвому припарки, по принципу "выкрасить и выбросить" т.к. общая архитектура ФС - древнее окаменелое г-но мамонта и это никакими костылями не лечится. И есть ZFS, которому оно такое нахрен не нужно, потому что он использует свои методы "журналирования", которые ему еще и разные эффектные фокусы позволяют. И вообще, версионноподобные ФС - выглядят перспективнее, а там как раз вся соль в специфичных техниках журналирования, которая и придает ФС интересные свойства, так что реализованные подсистемы журналинга остаются не у дел. И ради чего все это было затеяно? Неплохое общее решение, да. Только в общем то неперспективное и никому не сдавшееся в 2010 году. Вот чем-то таким инженерный подход и отличается от академического. Академики делают красивые вещи ради красоты. Инженеры делают нужные вещи для использования в реальной жизни.
> Да монолитное узкоспециализированное решение _возможно_ будет быстрее, но оно _точно_
> будет узкоспециализированным.
Специализированные решения всегда лучше по параметрам чем общие. И не всем и не всегда нужно общее решение на все случаи жизни. А зачем например VPN серверу провайдера быть чем-то еще, кроме VPN сервера? Он и в этом качестве будет загружен по полной, например, так что ничего другого на него всерьез и не взвалишь. А вот то что серверов потребуется в 2 раза меньше - однозначный PROFIT, при том очень весомый. Т.к. хорошие мощные сервера - они денег стоят, приличных весьма. И реально существующие компании как-то должны, знаете ли, жить и развиваться на тот доход который у них есть. Если сэкономили в 2 раза на серверах - значит будет больше прибыли, больше возможностей маневра и развития, больше шансов не сдохнуть под натиском конкурентов. Это же элементарно, Ватсон! :)
