13.05.2012 20:15, Victor Wagner пишет: > On 2012.05.13 at 19:10:53 +0400, "Артём Н." wrote: > >> 13.05.2012 18:34, Victor Wagner пишет: >>> On 2012.05.13 at 16:45:37 +0400, "Артём Н." wrote: >>> >>>> 13.05.2012 15:18, Victor Wagner пишет: >>>>> Кто что посоветует? >>>> FWBuilder. >>>> Плюсы: >>>> 1. Симпатичный ГУИ. Всё достаточно ясно и понятно. >>> Однозначный минус. Машина позволяет доступ извне, а значит будет >>> конфигурироваться извне, в том числе и по GPRS. >> Конфигурировать вы будете тоже на этой машине? > > Да, естественно. Потому что то что в руках, может быть телефоном, > андроидным планшетом, корпоративной рабочей станцией, где ssh-клиент > есть, а никакого стороннего софта ставить нельзя или вообще машиной из > интернет-кафе. Вы будете конфигурировать файрвол на машине из интернет-кафе? Корпоративные рабочие станции, я так думаю, конфигурируются централизованно. Конфигурировать планшет - неудобно, в плане того, что неудобно вводить длинные команды (ну, мне удобно на обычной клавиатуре). В любом случае, думаю, намного проще сделать скрипт на локальной машине и скопировать его, куда нужно. Через ssh клиент, например, с целевой машины. Частности. В случаях, когда нет под рукой локальной машины... А так часто приходится конфигурировать файрвол?
> Я и почтовый клиент-то запускаю обычно именно на этой машине. Потому что > как ни странно работа с почтовым ящиком по imap тормозит сильнее, чем > работа с интерфейсом mutt-а по ssh. Опять же, почтовым клиентом вы пользуетесь постоянно. А файрвол конфигурируете часто? >> Это интерфейс, прежде всего. Он позволяет создать скрипт. > Интерфес для создания скриптов называется текстовый редактор. > Любой другой интерфейс для этой цели по определению хуже. Мда? Так тогда и dpkg-reconfigure не нужен, например. :-) Зачем делать вручную то, что возможно автоматизировать? И зачем использовать универсальный инструмент, там, где его использование не оправдано? >>> Большего извращения чем компиляция неудобочитаемого языка в >>> удобочитаемый представить себе не могу. >> Не сказал бы, что это извращение. XML - формат хранения. > >> Он удобен для описания данных и, следовательно, обработки парсером. > > XML неудобен ни для чего. XML рекомендован W3C. Но я не специалист. Вероятно, вам знать лучше, а разводить холивор не хочется. > В качестве формата хранения удобене txt.lzma. > XML-ем пользуются те, кто не осилил контекстно-свободные грамматики и > yacc (я уж не говорю про рекурсивно-нисходящие парсеры. Не осиливший > yacc их тем боллее не осилит). Это к разработчикам программы. XML - унифицированный формат. Создавать свою грамматику и парсер под неё или использовать готовые библиотеки или генераторы парсеров для специфичного языка, - дело разработчиков. Вероятно, выбор XML был для них чем-то оправдан. > >> Целевой формат значения не имеет. Он предназначен, прежде всего, не для >> чтения, > > Если человек использует где-либо формат, предназначенный не для чтения, > за исключением формата зашифрованных сообщений, его из архитекторов надо > гнать поганой метлой. Интерпретаторы, умеющие интерпретировать > человекопонятные языки, научились писать за несколько десятилетий до > того, как изобрели XML. За прошедшее время в теорию парсеров языков > программирования вложено столько человеко-лет труда, что написать с > использованием имеющихся инструментальных средств парсер > человекочитаемого языка, который бы работал медленнее интерпретатора > байткода способны только отдельные гениии, вроде Страуструпа. Ну да, Страуструп, гений, блин. :-| Но, насчёт байт-кода вы, пожалуй, переборщили. Если в интерпретаторе не используется компиляция в тот же байт-код, наверное, разбор текста будет работать, в любом случае медленнее, чем исполнение "шитого кода" например, в интерпретаторе? Ну это вопрос и лирическое отступление. Там-то целевой язык - sh. И скрипт вполне читаем. >> И так, между прочим, часто делают. Не считая, что тут какие-то извращения >> есть. > > Я знаю. Некоторые, подобно авторам D-Bus, еще и хвалятся тем, что > используют никому непонятные бинарные форматы, маршаллинг которых > работает медленнее типичных интерпретаторов скриптовых языков. Возможно, кое-где и есть переборы. >> а для обработки интерпретатором. Удобочитаемость, в данном случае, просто >> дополнительный плюс. >> По-моему, большим извращением является ещё один язык над CLI iptables. >> >>>> 3. Библиотека служб, подсетей, времени и прочего. >>> Если для такой простой задачи нужны библиотеки, значит имеется >>> gross misdesign. >> Я не совсем правильно выразился. > Я вас правильно понял. Когда человек использует библиотечную функцию, он > как правило, не понимает что под этим кроется. o.O Так это получается, что glibc не нужен. И qt? И Boost, и STL (вот в данных случаях, кажется, мало кто понимает, что под ними кроется). > Поэтому в столь примитивных случаях библиотеки - зло. Если серьёзно, там нет зла. Это просто удобство. Читайте не библиотека, а "база данных" (грубо). Например, для того, чтобы расшарить каталог для win, мне надо открыть три порта. Я сейчас не помню какие порты использует NetBIOS, Wins и SMB. Зачем вбивать порты, когда есть предустановленные профили? >> Вас смущает GUI? >> По-моему, визуальное представление гораздо проще воспринимается, чем строки >> языка (да и есть множество серьёзных графических языков). > А по-моему нет. Но это уже особенности восприятия. Не скажите. Схема всегда понятнее кода. Хотя бы потому, что больше возможно охватить в целом. > К тому же в Linux > сейчас нет удобных gui-тулкитов, поскольку XView помер, а ничего > сравнимого по удоству с openlook-ом никогда не было создано. Авторы всех > прочих тулкитов начиная с моего любимого Tk и Моtif-а ориентируются на > копирование интерфейсных решений, придуманых в графических средах с > кастрированной мышью - либо двухнопочных виндах, либо вообще > однокнопочной Apple. Хотя для X-ов надо писать так, чтобы без средней > кнопки работать было неудобно. Потому что только тогда при ее наличии > будет работать эффективно. > >> А ошибки в архитектуре, вряд ли там присутствуют. > Если они до сих пор присутсвтуюуют в ядре Linux... Ядро неизмеримо сложнее. >> Развивается эта штука около 12 лет, работает на множестве ОС, поддерживает > > Переносимость - это плохо. o.O > Разные ОС имеют разную идеологию ядерных > файрволов. Потому попытка унифицировать работу с ними приведет к тому, > что будет использоваться только небольшое общее подмножество > возможностей. То есть самые вкусные вкусности конкретного файрволла > окажутся недоступными. Почему? Достаточно вынести платформозависимую функциональность в библиотеку. > Да, GUI это тоже касается. Программы с > "перенсимым GUI" смотрятся чужеродно во всех средах, в которых они > работают. Хм... Не всегда. GUI, конечно, ограничивает возможности. Но так ли часто требуется что-то специфическое? К тому же, это возможно самому дописать. Это просто удобный инструмент. Генератор rc.firewall. Удобство в наглядности, простоте настройки, переносимости. Мне нравится. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
