Почему Open Source? Точка зрения разработчика

ВЛАДИМИР ПОПОВ

Почему Open Source?

Точка зрения разработчика

Движение Open Source (под движением в данном случае понимается деятельность не только Open Source Foundation, но и всех ее сторонников и «идеологических» союзников) в настоящее время носит уже столь массовый характер, что не замечать его просто невозможно. Перспектива использования «свободного» ПО возникла и перед коллективом, на протяжении многих лет занимающимся разработкой и эксплуатацией АСУТП в аэрокосмической области. Размышлениями, результатами и приобретенным в ходе первой попытки использования свободного ПО опытом мы хотим поделиться. Итак, по порядку...

Цена

Да, господа. Время изменилось, и разработка начинается с экономического планирования. АСУТП, к сожалению, не бывают бесплатными, да и просто дешевыми. Для управления технологическим процессом обязательно потребуются УСО (устройства связи с объектом) и, как правило, технологические компьютеры, отличающиеся от ставших уже всем привычными персоналок многим, что потребовалось для достижения большей надежности, и, конечно, ценой. За эти компоненты системы придется платить вне зависимости от того, являетесь вы приверженцем Microsoft или Linux, но разница обнаруживается уже здесь: довольно часто одни и те же пакеты для разных платформ имеют разную цену, и почему-то для Windows NT стоят дороже. Оставим это на совести фирм-разработчиков этих пакетов... Перейдем от ПО специального к ПО широкого назначения, которое в состав комплекса тоже входит, если входят в его состав компьютеры широкого назначения, а это, как правило, так. Здесь, конечно, преимущество за свободным ПО: оно «почти» бесплатно. Надо сказать, что речь идет о суммах не столь уж малых: не Windows-98 придется покупать, а средства разработки. Следующее, что нужно учесть при рассмотрении экономического аспекта проекта, – это зарплата программистов, то есть непосредственных исполнителей. Отметим только, что затраты по этой статье не зависят от того, для какой операционной среды и какими средствами работают эти самые программисты. Сказанное справедливо, по крайней мере, для организаций бюджетных или лишь недавно утративших свой государственный статус. И последнее по поводу финансов. Все вышесказанное – попытка оценить себестоимость, основную составляющую цены, за которую созданный продукт может быть продан. Цена же – оружие в конкурентной борьбе, и не нужно от этого отмахиваться: занятно было видеть, как реагировал партнер «с востока», когда узнал, что при исполнении проекта на Linux необходимый SCADA-пакет обойдется ему в полтора раза дешевле, а для рабочих станций Windows-2000 вообще покупать не нужно. Далее...

Мораль

А может, обойдемся без покупки лицензионного ПО? Как раньше?... Вот об этом пришлось забыть сразу по нескольким причинам. Во-первых, уровень открытости таков, что очередной гость может оказаться и представителем почтенной Microsoft – вот неловко-то будет... Во-вторых, потому что сделанное даже для себя – все-таки товар, и продать его – мечта любого разработчика, а в такой ситуации использование «пиратского» ПО уже не просто неэтично – недопустимо. В-третьих, стоимость этого ПО в составе комплекса все-таки не является определяющей: чтобы оно не оказалось «ложкой дегтя», отбросим сомнения: восторги по поводу «доступности» коммерческого ПО на просторах пост-СССР оставим старшеклассникам и постараемся «играть» по общепринятым в мире правилам, хотя бы в области собственных разработок. А на офисные компьютеры глаза закроем, будем полагать: пока. Да и не только моральный аспект следует принимать во внимание, предполагая использование нелицензированного ПО: 400 млн.долларов прямых убытков Украины после введения санкций за нарушение прав интеллектуальной собственности впечатляют. Итак, размышления для нас закончились тем, что, по крайней мере, оценить возможность использования свободного ПО при создании задуманного комплекса – стоит. Приступим...

Первые впечатления. Возможности

По-прежнему предметом изложения будет только личный опыт. Для начала можно отметить одно обстоятельство: в ОС для технологических компьютеров отчего-то легче угадывается родство с UNIX-клоном, нежели с Microsoft Windows. Удивительного в этом ничего нет, если принять во внимание историю развития вычислительной техники последних 20-ти лет, но для «неофитов» от Microsoft может показаться странным, что OS9000 для PowerPC имеет больше общего с UNIX, чем с MSDOS. Другими словами, стремление сузить количество используемых операционных систем «подталкивает» скорее к UNIX, нежели к Microsoft Windows.

Во-первых, нам предстояло выбрать ОС для рабочих станций. Выбор, как выяснилось, достаточно широк: Linux, FreeBSD и т. д. Все названные ОС, как и их антиподы из мира коммерческого ПО, являются ОС общего назначения. На другое мы, собственно, и не рассчитывали, но было приятной неожиданностью узнать, что лидер по популярности среди свободных ОС – Linux – имеет как минимум две реализации, ориентированные на работу в условиях реального времени: RT Linux и KURT. Функционально аналогичные расширения существуют и для Windows NT, но... не бесплатные, как вы уже догадались. Но это к слову: наши требования к ОС для рабочих станций не выходили за пределы возможностей любой из названных ОС. Быть может, чуть заманчивее выглядел Linux: чего только на нем не делают... И роботы, и PDA, и коммуникационное оборудование... И почти все это можно посмотреть... Заманчиво. Пробуем Linux!

Прежде всего нас интересовали коммуникационные возможности. Как и следовало ожидать, все сетевые средства UNIX оказались в нашем распоряжении. А средства эти многого стоят. Несмотря на все старания Microsoft связать свое имя с сетями, у специалистов последние ассоциируются все-таки скорее с UNIX. Достаточно вспомнить попытки противостояния MicrosoftNet-Internet, NetBEAU-TCP/IP, и можно смело предположить, что на коммуникационные средства UNIX положиться можно. Что мы и сделаем.

Далее для нашего комплекса нужна была сетевая СУБД: не слишком сложная (откуда сложные запросы в АСУТП?), хорошо адаптированная к использованию в сети и с минимальным временем обработки запросов. Вряд ли хорошим кандидатом на эту роль можно считать Microsoft SQL: довольно высокие аппаратные требования, абсолютные требования к платформе сервера, неважные отзывы о скоростных характеристиках. Что же касается визуальных средств генерации форм и запросов, то почему-то они нас не заинтересовали. Лидер рынка, Oracle, также не стал нашим выбором, хотя его SQL-сервер уже готов был работать на любой платформе, включая Linux. Не оставляло ощущение, что мы будем «стрелять из пушки по воробьям». Среди представителей свободного ПО наше внимание привлек MySQL. Скромные размеры, популярность в качестве SQL-сервера в Интернет, работает на всех платформах. Даже недостатки его в нашем случае выглядели достоинствами: неумение работать с так называемыми record-set-ами, как и некоторые другие «изъяны», оказались нам совершенно не нужны: высокая реактивность и компактность, которые вряд ли бы выиграли от расширения возможностей сервера, для нас были значительно важнее. Открытый код позволяет написать интерфейс к этой СУБД практически для любой вычислительной системы, в которой есть С-компилятор и которая умеет работать с TCP-сокетами (обязательно сделаем это для OS9000). Популярность в Интернете сделала свое дело: на www.mysql.com, кроме API для ansi «C», написанного разработчиками самого сервера, можно обнаружить API для «С++», Java, а для Perl – даже несколько, с разными скоростными характеристиками, написанными независимыми разработчиками. Масса средств редактирования и администрирования: от консольных, принадлежащих перу авторов, до графических для любых платформ, включая Microsoft Windows. Есть и средства доступа через веб-интерфейс (как раз это мы предполагали разработать для удаленного контроля с компьютеров, не являющихся частью сетевого сегмента комплекса). Одним словом, «глаза разбегаются». Пожалуй, и этот выбор мы сделали.

Наверное, можно было бы и не рассказывать, что когда нам потребовался http-сервер для организации удаленного администрирования через веб-интерфейс, мы использовали Apache – самый популярный http-сервер в Интернете. Хотя пробовали и thttpd, заинтересовавшись его скоростными возможностями: действительно – быстро. Только когда дошло до вывода таблиц объемом в сотни килобайт, что-то наш thttpd «засбоил» и, не желая терять время на выяснение в общем-то второстепенных для нас деталей, мы вернулись к Apache.

Теперь предстояло определиться со средствами реализации графического интерфейса АРМ рабочих станций. И здесь свободное ПО оказалось на высоте. XFree86 если и уступает MS Windows, то только в скорости графического вывода и количестве поддерживаемых видеокарт. Что касается второго, то действия производителей видеоадаптеров, снабжающих свои изделия прежде всего драйверами для самой распространенной ОС для десктопов, естественны. Что же до скорости, то сравнение несколько некорректно: сравнивать нужно исключительно с Windows NT, а еще точнее – с ее терминальным сервером, поскольку XFree86 – сервер, действительно способный обслуживать сразу несколько клиентов: десктопов или сетевых станций. Признаться, мы были приятно удивлены. Во-первых, количеством доступных оконных менеджеров (а именно они определяют вид и возможности десктопов в X-Window), во-вторых, их качеством (очень трудно найти возможности, которые имели бы Microsoft Windows, но не имели бы последние версии KDE или Gnome, зато обратное возможно, и это, прежде всего, возможности настройки), в-третьих, количеством так называемых «тем» (сам менеджер обычно определяет возможности десктопа, внешний же вид – функция темы). Однако мы увлеклись: для нашей задачи нас интересовали практически только возможности настройки поведения окон и системы управления (меню, инструментальные панели и т. п.). Здесь мы остановили свой выбор на IceWM: одном из самых «аскетичных», но в то же время быстрых и надежных оконных менеджеров. Большего, признаться, мы не могли желать: большинство из известных вариантов поведения окон («всплывание», «скрывание», вывод на «передний план», «активность» в зависимости от положения указателя мыши или кликов (разными бутонами и разное количество раз), или действий приложения); поддержка трех бутонов мыши, «колесика» (scroll); множество десктопов; абсолютно настраиваемые меню и инструментальная панель. На последнем хочется остановиться подробнее: фактически, мы получили заготовку для «заглавного» окна нашего АРМ, поскольку ни единого элемента, заданного не нами на экране, просто не было. Более того, пользователь оказался практически лишен возможности изменить настройки десктопа или выполнить команду, кроме тех, которые предлагает ему АРМ. Наверное, кому-то такой подход к пользователю покажется «иезуитским», но поверьте: ограничение возможности ошибки оператора весьма и весьма насущная задача для АСУ. Похоже, все необходимое мы нашли. Можно было переходить к реализации, что и было сделано.

Работа

Прежде всего мы определились со средствами программирования: в нашем распоряжении были С, С++ и Perl. Конечная реализация на C/C++ сомнениям в общем-то не подвергалась, а вот «макетирование» с использованием Perl интересно было попробовать.

Впервые в наших руках был интерпретатор, имеющий доступ практически ко всем возможностям ОС, допускающий объектную ориентацию и довольно близкий по синтаксису к С. Коммуникационные, впрочем, и все другие возможности ОС доступны из Perl через общие с С библиотеки. API к MySQL – аналогичны. Что же касается графических библиотек Tk и Gtk (мы использовали только эти), то модуль Gtk-Perl делает возможными обращения к собственно объектной библиотеке Gtk, а модуль Perl-Tk имеет даже собственные расширения этой весьма популярной в мире UNIX-графической библиотеки. Одним словом, все необходимое было налицо и мы не обманулись в своих ожиданиях. Справедливости ради нужно сказать, что среди средств разработки под Linux существуют интегрированные среды, ставшие привычными в последнее десятилетие стараниями, прежде всего, Borland и Microsoft, однако мы их пока не использовали, поэтому и не упоминаем. А вот некоторые другие моменты упомянуть необходимо.

Во-первых, это вопрос документации. Слухи об исчерпывающей документированности Linux не оказались преувеличением. Скорее наоборот: документации слишком много, что не облегчает поиск. Беда в том, что желающих написать и опубликовать в Сети тот или иной документ оказывается больше, чем желающих изъять устаревший, неполный или уже неактуальный более (в силу появления новых) документ. Тем более, что это все-таки прерогатива автора, который, не исключено, на настоящий момент уже и забыл о собственном детище. Издержки свободы? Возможно, но это все-таки лучше, чем отсутствие документации. Можно возразить, что MSDN – тоже весьма обширный источник информации, но различие в информации о том, «какие API-вызовы нужно использовать» и «как именно реализована эта функция и почему ее лучше использовать именно так» все-таки заметны. О цене «Microsoft Developer Network Library» я вообще умолчу...

Во-вторых, безусловно, приятно ощущать дух сотрудничества, всегда присутствующий в общении разработчиков Open Source. Благодарность предшественникам, присутствующая в любом readme, сопровождающем пакет свободного ПО, не только «хороший тон» – это, как правило, благодарность искренняя и небезосновательная. CPAN, freshmeat, SourceForge – прекрасные иллюстрации этому. Буквально «горы» ПО с открытым исходным кодом, отсортированные, часто прекрасно документированные и буквально «пропитанные» духом сотрудничества.

В-третьих, часто, хотя, наверное, не всегда, это высокий профессионализм. Представить свой код на всеобщее рассмотрение можно или будучи вполне уверенным в его достоинствах, или не отдавая себе отчет в собственной некомпетентности. Второе, конечно, не исключается, но все-таки, скорее, исключение, чем правило: что-то я не слышал о программистах-графоманах.

Наверняка, наше знакомство со средствами разработки, являющимися ПО с открытым кодом, не позволяет судить о состоянии этого сектора индустрии «в целом», но понравившиеся продукты хочется назвать. Это прекрасные компиляторы gnu C и C++; поражающий своей продуманностью и модифицируемостью редактор vim; интерпретатор, способный соперничать в скорости с откомпилированными задачами, – Perl; охватывающая, кажется, все возможности программирования в графической среде библиотека Tk, и изысканная, даже авангардная Gtk. Мы не перечисляем «исконные» программы UNIX, такие как grep или diff, поскольку они не являются частью исключительно свободного ПО, но признаем, что наличие этих программ в свободных ОС, безусловно, их сильная сторона.

Результат

Как, собственно, следует из изложения, он положителен. Мы считаем опыт использования свободного ПО для разработки комплексов АСУТП удавшимся.

Последняя особенность, которую мы вполне оценили только на последнем этапе – это командный язык, позволивший посредством создания очень простых командных файлов объединить независимые части комплекса, скрыть от оператора сложность некоторых действий, а привязав эти файлы к процессу загрузки и используя возможности демонов периодического запуска, мы придали системе иллюзию «автоматичности». Эти возможности опять-таки не являются прерогативой Linux и свободных ОС вообще: все это достоинства UNIX, но не остановись мы на Linux, эти достоинства так и остались бы для нас известными только понаслышке.

Одним словом, так как когда-то мы перешли от RSX и RT к продуктам Microsoft, так сейчас склонны расстаться с последними в пользу свободного ПО. Тому много оснований: экономических и идеологических, политических и технических, ни одно из которых не является, правда, определяющим. Но попробовать стоит.

У нас получилось.