ТехноСаратов → Блог

Философия UNIX*n?xБлог

Multitoolbox — новый сайт от создателей этого поратала

В последнее время у меня образовалось много новых мыслей по поводу UNIX сист… ем, которые я тут и хочу представить на общий суд. Надеюсь, что у меня получится сделать это более-менее интересно.

Все познается в сравнении, поэтому я буду сравнивать UNIX с ее единственным оставшимся конкурентом — Windows. Множества областей применения этих ОС перекрываются не полностью, и рассуждать какая из них лучше занятие неблагодарное. Ведь единственно верного пути не существует, и нет в природе «серебряных пуль» на все случаи жизни. По тому я попробую больше концентрироваться на фактах, оставляя окончательную оценку за читателем, который, исходя из конкретных условий в которых он находится, сможет сказать является то, или иное свойство для него плюсом или минусом.

ОС UNIX — это система от программистов и для программистов, так было всегда, так остается и поныне. Смысл этого выражения заключается в том, что использование UNIX — это циклический процесс написания программ и их применения. Написать однострочный скрипт, для пользователя UNIX настолько же естественно, как пользователю Windows пару раз щелкнуть мышкой. Но в отличие от последнего, юниксоид запускает не одну программу, а комбинацию программ работающих друг с другом. Отсюда укоренившееся выражение, что — «пользователь знает лучше» как, где и в комбинации с чем применять написанную разработчиком программу. Это называется предоставлением механизма использования программ, в противоположность предоставления политики их использования, когда пользователь не может заменить составных частей программы.

Предоставление политики удобнее для неквалифицированных пользователей, либо когда заведомо известны все шаги, которые должна выполнять программа (например, во встраиваемых системах). Однако написать оболочку для ряда взаимодействующих программ, предоставляющую политику их использования возможно (с использованием tcl/tk), а вот разбить монолитный кусок объектного кода на составляющие, чтобы их мог использовать квалифицированный пользователь нереально.

http://technosaratov.ru/galleries/29/550.jpg
Пример GUI оболочки на tcl/tk.

Но если модульность настолько удобна, почему же ее не используют в Windows? На самом деле это вовсе не проблема Windows как таковой. Хотя дороговизна создания новых процессов в этой ОС и накладывает некоторые ограничения на чрезмерное (с точки зрения Windows) разделение программ на модули, основной проблемой является доминирующая модель бизнеса вокруг этой ОС. Большинство лицензий напрямую запрещает редистрибутизацию программ, каждая фирма пытается стать лидером в своей области не за счет выпуска действительно качественного ПО, что очень дорого, а за счет сокрытия механизмов использования. Выпуск программы в виде модулей поможет развитию их конкурентов, которые, в свою очередь, могут быт не столь благосклонны и могут не предоставлять механизмов использования своих программ.

dotNET в некоторой степени решает эту проблему. Разделение проекта на отдельны модули (сборки) стало гораздо проще, программисты могут выберать из множества уже готовых модулей (коммерческих) и встраивать их в свою программу. Однако конечный пользователь никогда не сможет заменить один модуль другим, из-за сильного связывания, то есть никогда не сможет воспользоваться механизмом, т.к. ему предоставлена только политика использования программы с жесткой привязкой к GUI логикой.

Другая технология предоставляющая возможность удобной модульной разработки приложений — Java. Но модульное использование Java программ сводится к минимуму из за дороговизны запуска программ. Хотя написание серверов на Java, запускаемых один раз, вполне оправдано, то есть не скрывает механизма и позволяет минимизировать издержки архитектуры.

Другим преимуществом модульности является возможность использования различных языков и средств разработки.

Я полностью согласен с постом GoD

GoD:

все эти реализации под .нет это попытка реанимировать языки и что бы специалисты в них могли быть конкурентно способны на рынке труда. так наприм делфи .нет и т.д. но это имхо)

#

Но только в контексте разработки корпоративнх программ. Использование разных языков в этом случае ведет к дороговизне или даже вообще невозможности сопровождения. Уволившийся во время проекта разработчик, на каком нибудь Haskel, приведет к полному завалу проекта, либо к переписыванию его кода с нуля на той же Java или C#. А программист одиночка таким же образом может навечно привязать к себе, ничего не сведущего в жизненном цикле программ, заказчика и диктовать ему свои условия.

Все это конечно плохо. Но есть и другие виды проектов, в которых либо вовсе не обойтись без квалифицированных исполнителей (научные проекты, экспертные системы и т.п.), либо сопровождение программ не требуется вообще.

Многие беды программного обеспечения заключаются в политике фирм разработчиков. Каждая из них пытается завоевать лидирующее место на рынке по тому просто вынуждена постоянно выпускать новые версии, даже когда в них нет нужды. А многие занимаются выработкой этой необходимости перед выпуском новых версий. В противоположность некоторые утилиты UNIX не обновляются по десять лет, т.к. нет необходимости в новых функциях, большинство ошибок отловлены, пользователи привыкли к существующим интерфейсам модулей и с их использованием написано много программ. Таким образом, поддержка модульного приложения обходится гораздо дешевле и языки, используемые для отдельных модулей, не так важны, ведь если модуль написан качественно, то время его сопровождения (поиска ошибок, доработка интерфейса) гораздо меньше времени его использования. Значит выбираемый язык не критичен, лишь бы он не вызывал дополнительных проблем при развертывании приложения, не требовал установки дополнительных пакетов.

Как всегда платой за слабое связывание является большое количество зависимостей, и поиск программ конкретной версии, для запуска приложения не может не огорчать, однако эта проблема должна решаться дистрибостроителями, либо сопровождающие должны подправлять программы под используемые клиентами дистрибутивы. И для большинства программ решена наилучшим образом. Например, не так давно мне пришлось устанавливать trac+svn на FreeBSD, и помня былой опыт установки под Windows я приготовился к долгой и изнурительной работе по подбору правильных версий пакетов (благо большинство на Python, хотя бы компилировать не нужно), но нашел все необходимые пакеты на ftp.san.ru и без труда установил простыми командами pkg_add. Так, что на самом деле большой проблемы при использовании разных языков программирования нет ни для пользователя ни для разработчика, а последний даже может ускорить таким образом процесс разработки.

Для монолитных ООП программ, слабое связывание объектов также является приоритетной задачей, но сопряжено как правило с раздутым среднем соединяющим их уровнем. Количество абстракций, не привязанных к конкретному функционалу, а только реализующих слабое связывание основного кода часто просто поражает. Программисты на столько погружаются в процесс порождения сущностей, что уже забывают основную цель своей работы — написать работающую программу. Основной их аргумент в том, что такая программа будет легко изменяемой, а следовательно легко сопровождаемой. На самом же деле, программа легко сопровождаема, когда прозрачна, проста, коротка и не изобилует лишними связями. Намного легче переписать сотню-две строк структурного кода, чем разбираться во всех хитросплетениях ОО кода. Уверен, что использование объектно-ориентированного программирования и монолитные структуры оправданы в случае моделирования сложных систем, когда выделение отдельных объектов в модули и объединение их посредством механизмов межпроцессного взаимодействия невозможно, т.е. утолщает средний связывающий уровень сложными протоколами и множественными связями между процессами. В иных случаях, простой системный конвейер (операция «|» командного интерпретатора) реально может заменить десятки строк кода.

Применение различных языков программирования в одном проекте, также сокращает средний связующий уровень, т.к. на каждом из языков что-то получается писать гораздо лучше. Например, зачем мучиться с обработкой сигналов от кнопочек на Си, когда это элегантно делается с помощью tcl/tk? Зачем мучиться с обработкой текстовой информации, когда для этого можно использовать sed, awk, grep…? Правильно, незачем. Как правило, при этом пользователи ноют, что приходится читать много мануалов, ну а разве вы не читаете мануалы при изучении новых инструментов программирования? Но это конечно не значит, что конечный пользователь должен читать мануалы. Правильно написанная модульная программа включает в себя отдельный GUI, который и применяют обычные пользователи в ежедневной работе. Тут можно вспомнить недавно описанную мной программу QEMU. r007 прав, что консольный интерфейс неудобен, тут не поспоришь. Вспоминать каждый раз все флаги — это пустая трата времени, по этому QEMU нуждается в GUI и он есть, но поставляется отдельно. Связывать GUI с программой — это забота дистрибостроителей, а не разработчиков и не пользователей, т.к. пользователю может еще захотеться связать QEMU с отладчиком, какими-нибудь еще средствами контроля и разработчик не может всего этого учесть, так что лучшими вариантами будет либо вовсе не создавать GUI, оставив эту проблему другим, либо создать GUI отдельным модулем, который дистрибостроитель всегда может заменить лучшим.

http://technosaratov.ru/galleries/29/551.jpg
GUI оболочка для QEMU. Заметна рука любителя 🙂

Более того, пользователь часто может применять те программы к которым уже привык в новых контекстах. Например, gdb можно вызывать из vim, а vim также использовать в качестве редактора для почтового клиента mutt. Поэтому часто создание пользовательских интерфейсов также сводится к интеграции уже имеющихся модулей, к которым пользователь привык. Причем часто это делается на «полном автопилоте». Например, многие утилиты используют пейджер more, чтобы его сменить на более новый less достаточно изменить переменную среды PAGER, а для выбора редактора писем почтового клиента mutt, достаточно поместить имя редактора в переменную EDITOR.

Последним преимуществом UNIX систем является открытость. То что может изменяться и настраиваться, всегда изменяется и настраивается стандартными средствами ОС, такими как текстовый редактор. Все конфигурационные файлы, многие базы данных выполнены в текстовом формате, и, возможно, сжаты стандартными архиваторами для уменьшения занимаемого размера. Тоже самое касается сетевых протоколов и логов. Хотя есть и бинарные сетевые протоколы, но предпочтение почти всегда отдается текстовым, которые проще анализировать, отлаживать и расширять. А для экономии трафика сетевой поток, также часто сжимается стандартными средствами.

Чтобы подвести итог, всему выше написанному, рассмотрим области применения этих систем. Во первых, так как они противоречат современной бизнес модели софтверной промышленности, то ждать их появления в мелком и среднем бизнесе в ближайшее время не стоит. В офисах тоже, т.к. нет пока такого офисного дистрибутива, который можно было бы использовать без поддержки квалифицированного администратора. Появление в школах, которого так долго ждут, скорее всего произойдет в конце 2010-го года, т.к. государство пока объявило о том, что больше не собирается оплачивать коммерческое ПО, школы перевели на новую форму оплаты и они могут теперь сами распоряжаться, что выплатить учителям, а что потратить на виндус, фотошоп и иже с ними. Те сферы, где UNIX применяются сегодня (наука, интернет и прочие коммуникации, крупный бизнес) врятли ждут изменения, если только следующая версия Windows не станет UNIX Like 🙂

PS: основные мысли этой статьи я почерпнул из книги Art of UNIX Programmung, которую всем рекомендую к прочтению, как довольно легкое и одновременно глубокое произведение.