«Четвёртая конференция разработчиков свободных программ на Протве Обнинск, 23–25 июля 2007 года Тезисы докладов Москва, Институт Логики, 2007 В книге собраны тезисы докладов, одобренных Программным комитетом Четвёртой ...»

При поддержке

Министерства информационных технологий и связи

Российской Федерации

АНО «Институт логики, когнитологии и развития личности»

ALT Linux

Четвёртая конференция

разработчиков свободных программ

на Протве

Обнинск, 23–25 июля 2007 года

Тезисы докладов

Москва,

Институт Логики, 2007 В книге собраны тезисы докладов, одобренных Программным комитетом Четвёртой конференции разработчиков свободных программ.

Круг рассматриваемых тем весьма широк: от новейших системных и прикладных разработок до правовых проблем, вопросов организации работы в проектах и аналитики.

c Коллектив авторов, 2007 Программа конференции 22 июля 20.30–22.00: Регистрация в холле гостиницы 23 июля 10.00–12.30: Регистрация в холле гостиницы 12.00–12.30: Кофе Дневное заседание 12.30–14. 12.30–12.40: Открытие конференции 12.40–13.20: Доклад представителя Министерства информационных технологий и связи Российской Федерации Алексей Смирнов Свободное программное обеспечение для государства и общества........................................ — 14.00–14.45: Обед 4 Программа конференции Вечернее заседание 14.45–19. Константин Осипов Процесс разработки ПО в MySQL: проблемы роста........ Александр Боковой Кластерная самба.................................... Анатолий Якушин, Раиль Алиев Анализ международного и российского опыта перехода на стандарт ISO/IEC 26300:2006. Сравнительное исследование возможных решений по процессу миграции 16.05–17.05: Кофе-брейк Дмитрий Левин От SRPMS к GEAR.................................. Виталий Липатов Разработки Etersoft для миграции на Linux и вклад в сообщество...................................... Владимир Рубанов, Денис Силаков Центр верификации ОС Linux: вклад в развитие стандарта LSB и тестирование Linux-платформы............... 24 июля Утреннее заседание 9.30–14. Михаил Гильман, Андрей Михеев, Петр Михеев Проект DIFFR — открытая система для моделирования двумерных задач дифракции....................... Руслан Хихин Опыт использования Linux в ОАО «Концерн Моринформсистема „Агат“»........................ Георгий Курячий, Александр Потапенко Система хранения и публикации документации Babylon.... Алексей Гладков Сборочная система sisyphus (giter factory)................ 11.30–11.50: Кофе-брейк Программа конференции Андрей Михеев Проект RUNA WFE — свободная система управления Николай Шмырёв Синтез и распознавание русской речи с открытыми Рената Пожидаева Павел Сёмин 14.00–14.40: Обед Алексей Куклин Развёртывание и подержка мультисервисных серверов с применением виртуализации OpenVZ. Общие вопросы Михаил Якушин Опыт объединения технологий виртуализации и кластера Александр Московский Библиотека шаблонных классов С++ для поддержки Алексей Турбин 16.40–17.10: Кофе-брейк 17.10–19.00: Круглый стол по проблемам использования Свободного ПО в образовании. Ведущие: Н. Н. Непейвода (УдГУ, Ижевск), Г. В. Курячий (ALT Linux, Москва).

25 июля Пётр Козорезов, Роман Макаров, Алексей Федосеев Проект OpenPower: разработка открытого ПО на платформе Пётр Савельев Евгений Чичкарёв, Тамара Назаренко Оптимизация и статистический анализ: опыт разработки Георгий Курячий 11.45–12.15: Кофе-брейк Андрей Черепанов Сурен Чилингарян Кирилл Шутемов Григорий Баталов 13.55–14.45: Обед 14.45–15.30: Дискуссия 15.30–15.45: Алексей Новодворский, Москва, ALT Linux. Заключительное слово.

Вне программы Руслан Хихин Сизиф как феномен живого дистрибутива, или зависимости Проект: MySQL Процесс разработки ПО в MySQL: проблемы роста Данный доклад посвящён организационным аспектам разработки ПО на основе опыта MySQL. MySQL — распределённый открытый проект, за плечами которого стоит коммерческая компания с высоким уровнем организации и нацеленности на коммерческую выгоду. Начавшись как надстройка над существующей нереляционной базой данных, проект до 2001 года существовал во многом за счёт индивидуальных пользователей и их поддержки. В этот период разработка велась двумя-тремя инженерами во главе с Майклом «Монти» Видениусом, одним из основателей MySQL. Период 2001–2007 гг. — период бурного роста, когда и штат разработчиков, и масштабы компании удваивались ежегодно. Немногие проекты выживают в подобной ситуации, не будучи переписанными «с нуля», и ни для одного проекта подобного рода масштабирование не проходит без потерь. Наблюдениям и опыту «инсайдера» и посвящён этот доклад. Как программиста, меня в первую очередь интересовали технические аспекты процесса разработки, о них в основном и пойдёт речь:

• из каких частей или модулей состоит продукт;

• кто работает над разными модулями, группы;

• коммуникация — списки рассылки, IRC, этикет распределённого общения;

• средства управления версиями;

• процесс сборки и управление релизами;

• тестирование;

• личные аспекты — как выжить между молотом Калифорнии и наковальней Хельсинки;

• что такое по-настоящему «открытый проект».

Литература [1] Georey A. Moore Crossing the Chasm. »» »

[2] Torvalds L. Linus Torvalds talk on Git. »» [3] Ben Collins-Sussman, Brian W. Fitzpatrick How to protect your open source project from poisonous people. »» Проект: Samba Карнавальная самба — танец индивидуальный или групповой, поэтому Несмотря на активное развитие программных комплексов на основе веб-служб, обмен файлами в локальной сети с использованием специализированных протоколов сетевых файловых систем по-прежнему остаётся доминирующим. При этом за последнее десятилетие значительно выросли объёмы информации и усложнились типичные сценарии её использования: от однопользовательских приложений произошёл переход к многопользовательским, от монопольного владения файлами в рамках одной организации — к необходимости совместной работы над одними и теми же файлами в распределённой среде, где пользователи могут быть географически удалены друг от друга и от файл-серверов.

Традиционно в таких ситуациях используются кластеры для распределения нагрузки и повышения отказоустойчивости системы. Однако в случае файловых систем использование файлового кластера ограничивается следующими особенностями:

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

Вечернее заседание (14.45–19.15) • Во-вторых, сама файловая система, используемая узлами кластера для хранения файлов, должна поддерживать общую работу с этими файлами с разных узлов системы. Такая файловая система обычно называется кластерной или распределённой.

Забудем на время о первой особенности и обратимся ко второй.

На сегодняшний день существует несколько кластерных файловых систем, которые можно было бы использовать для организации такого распределённого хранилища: свободные GFS, OCFS, PVFS2, Lustre, коммерческие GPFS (IBM), CXFS (SGI), Lustre. Однако для всех из них существуют свои ограничения, главное из которых (помимо отсутствия поддержки некоторых свойств первой особенности) — отсутствие клиента для распространённых клиентских систем (Microsoft Windows, Mac OS X). То есть, для того, чтобы, скажем, клиенты из-под Microsoft Windows работали с файлами, размещёнными на GFS, необходимо использовать какую-то другую сетевую файловую систему, которая скорее всего не будет кластерной. Забегая вперёд, скажем, что на самом деле кластерных сетевых файловых систем для таких клиентов нет вообще.

Становится понятно, что в такой ситуации некоторого «медиатора»

не избежать. Таким «медиатором» уже давно является Samba, в рамках которой реализуются многие из функциональных возможностей сети Microsoft Windows: файловый обмен, печать, доменная структура. На практике можно было бы использовать Samba для доступа к файлам, хранящимся на кластерных файловых системах, и раньше, однако тут как раз важную роль играют составляющие первой особенности.

Допустим, что мы захотим разместить файлы на кластерной файловой системе и предоставить их клиентам посредством немодифицированной версии Samba. В этом случае нам необходимо будет удостовериться, что кластерная файловая система поддерживает блокировки файлов, к которым обращаются с разных узлов. Мы очень быстро убедимся, что из свободных реализаций только GFS умеет это делать относительно надёжно, но даже она не обеспечивает быструю работу с такими файлами. Из коммерческих систем это умеют GPFS и CXFS, однако их производительность тоже падает существенно (на порядки) по сравнению с неблокируемым вариантом. Это практически сводит на нет ценность такой работы.

Что же предлагается сделать? С одной стороны, необходимо модифицировать Samba для обеспечения совместной работы поверх клаиюля стерной файловой системы, с другой — нужно добиться таких изменений, которые не приведут к снижению скорости работы системы в некластерном варианте (один сервер). Над решением этой задачи Samba Team работала более шести лет, в рамках разных проектов и при поддержке разных компаний, которые были заинтересованы в получении этой функциональности. Только в 2006 году удалось реализовать прототип, который демонстрировал принципиальную возможность такой модификации с потенциалом роста производительности, о нём рассказывалось на предыдущей конференции. Затем по результатам оценки достоинств и недостатков полученного решения был разработан принципиально иной подход к кластеризации, позволивший получить существенные результаты: кластерная Samba работает быстрее обычной на одном узле приблизительно на 20–30 %, а при переходе к нескольким узлам скорость возрастает на два порядка.

Одной из архитектурных особенностей Samba является использование вспомогательных баз данных для обмена информацией между отдельными её компонентами. Эти компоненты могут исполняться в рамках разных процессов (и в случае кластерной реализации — даже на разных узлах), а данные могут жить как короткое время, на время отдельного запроса, так и в течение всего клиентского сеанса, который может охватывать несколько TCP-соединений.

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

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

Вечернее заседание (14.45–19.15) В результате те узлы, которые чаще работают с определёнными файлами, становятся ответственными за информацию о них, «перетягивая» на себя хранение и обработку соответствующих служебных записей в базах данных. При этом сами файлы находятся в кластерной файловой системе и их изменения видны другим узлам (и через них — другим клиентам). Если кто-то ещё обратится к этим файлам, информация о них будет запрошена у ответственного узла, который может перестать быть таковым, если запрашивающий станет активно работать с этими данными.

Таким образом, получается распределённая система, в которой ответственность за информацию о тех или иных ресурсах мигрирует с узла на узел следом за активностью пользователей, работающих с этими ресурсами через конкретный узел, а сама система следит за тем, чтобы процессы на разных узлах своевременно обменивались информацией между собой. Помимо обмена информацией система выполняет и ряд других функций: она следит за доступностью узлов и перестройкой кластера в случае падения узлов, за доступностью кластерной файловой системы и координации экспорта ресурсов через другие протоколы (NFS, HTTP,...).

Анатолий Якушин, Раиль Алиев Москва, OpenOce.org Анализ международного и российского опыта перехода на стандарт ISO/IEC 26300:2006.

Сравнительное исследование возможных решений 1 мая 2007 года исполнился год с того момента, как Всемирная организация по стандартизации (ISO) приняла формат ODF (OASIS Open Document Format for Oce Application) в качестве международного стандарта под именем ISO/IEC 26300:2006.

Прошедший год показал, что миграция на новый формат, даже признанный такой авторитетной организацией, как ISO, требует значительных усилий и творческого подхода, подчас соизмеримого с процессом создания нового формата данных.

Авторами проведён анализ международного и российского опыта практического перехода на стандарт ISO/IEC 26300:2006 правительственных организаций, муниципальных учреждений, а также предприятий различной формы собственности. При проведении анализа отдельное внимание уделялось исследованию сопутствующих процессу перехода правовых механизмов.

В качестве источников фактологического материала использовались открытые данных из сети Интернет, публикации международной организации ODF Alliance, статистические и аналитические материалы международного сообщества разработчиков OpenOce.org, а также прямые контакты с координаторами национальных проектов по разработке и внедрению программных продуктов, использующих ISO/IEC 26300:2006 через международный проект Native Language Confederation. Кроме этого, проводилось заочное выборочное групповое анкетирование активных участников проекта OpenOce.org.

В результате проведённого анализа были выявлены наиболее типичные сценарии процесса миграции на стандарт ISO/IEC 26300:2006.

Миграция «через стандарт» Наиболее масштабный и осознанный сценарий миграции, при котором основной задачей является внедрение стандарта ISO/IEC 26300:2006 в практическую деятельность, а собственно программные средства документооборота являются вторичными. Данному сценарию свойственна глубокая юридическая и техническая проработанность деталей, широкая зона охвата процессом внедрения (на уровне государства, региона или крупной компании), частые компромиссные варианты между использованием свободного и проприетарного программного обеспечения.

Миграция «через программное обеспечение»

вариант миграции, при котором основной задачей является внедрение свободного офисного приложения (наиболее часто OpenOffice.org), либо свободной платформы (как правило один из дистрибутивов Linux) с целью легализации используемого программного обеспечения и снижения издержек на закупку проприетарного ПО. При этом вопросы собственно использования ISO/IEC 26300:2006 отходят в данных проектах на второй план.

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

«Хаотическая» миграция Типична для небольших предприятий и организаций с низкой производственной и организационной дисциплиной, где выбор программного обеспечения для организации документооборота отдан на откуп сотрудникам. При данном сценарии один или несколько работников по разным побудительным причинам начинают использовать программные продукты, поддерживающих ISO/IEC 26300:2006. В этом случае собственно формат ISO/IEC 26300:2006 не используется даже для внутреннего документооборота ввиду внутриофисной несовместимости.

В заключение можно привести десять элементов стратегии перехода на стандарт ODF, впервые сформулированных Hasannudin Saidin, одним из идеологов Малазийского проекта, и позже расширенных и дополненных в рамках ODF Alliance:

1. Продолжайте использовать старое офисное программное обеспечение для обработки проприетарных форматов файлов до полного завершения процесса миграции.

2. Используйте только такое программное обеспечение, которое поддерживает кроме ISO/IEC 26300:2006 ваши старые форматы 3. Начинайте переносить свои шаблоны в формат ODF от простых 4. Чаще используйте Adobe Portable Document Format (PDF) при обмене информацией с внешними корреспондентами.

5. Старайтесь внедрить ODF сразу в рабочей группе или подразделении.

6. Выявите и обучите потенциальных местных экспертов и «гуру»

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

7. Установите точные правила и сроки по переходу на ODF.

8. Активно используйте ресурсы и информацию таких организаций, как ODF Alliance и OASIS ODF Adoption Committee.

9. Взаимодействуйте с другими организациями, заинтересованными в процессе миграции, в том числе и через национальные группы по поддержке OpenOce.org.

10. Настоятельно рекомендуйте разработчикам заказного программного обеспечения для вашей компании поддерживать в своих проектах ODF.

Проект: Sisyphus Основной смысл хранения исходного кода пакетов в git-репозитории [1] заключается в более эффективной и удобной совместной разработке, а также в минимизации используемого дискового пространства для хранения архива репозитория за длительный срок и минимизации трафика при обновлении исходного кода.

Идея gear [2] заключается в том, чтобы с помощью одного файла с простыми правилами (для обработки которых достаточно sed и git) можно было бы собирать пакеты из произвольно устроенного gitрепозитория, по аналогии с hasher [3], который был задуман как средство собирать пакеты из произвольных srpm-пакетов.

Структура репозитория Хотя gear и не накладывает ограничений на внутреннюю организацию git-репозитория (не считая требования наличия файла с правилами), есть несколько соображений о том, как более эффективно и удобно организовывать git-репозитории, предназначенные для хранения исходного кода пакетов.

Вечернее заседание (14.45–19.15) Одна сущность — один репозиторий Не стоит помещать в один репозиторий несколько разных пакетов, за исключением случаев, когда у этих пакетов есть общий пакетпредок.

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

Минусы: Несколько сложнее выполнять операции fetch и push в случае, когда репозиториев, которые надо обработать, много. Впрочем, fetch/push в цикле выручает.

Несжатый исходный код Сжатый разными архиваторами исходный код лучше хранить в gitрепозитории в несжатом виде.

Плюсы: Изменение файлов, которые помещены в репозиторий в сжатом виде, менее удобно отслеживать штатными средствами ( ). Поскольку git хранит объекты в сжатом виде, двойное сжатие редко приводит к экономии дискового пространства. Наконец, алгоритм, применяемый для минимизации трафика при обновлении репозитория по протоколу git, более эффективен на несжатых данных.

Минусы: Поскольку некоторые виды сжатия одних и тех же данных могут приводить к разным результатам, может уменьшиться степень первозданности (нативности) исходного кода.

Распакованный исходный код Исходный код, запакованный архиваторами (tar, cpio, zip и т. п.), лучше хранить в git-репозитории в распакованном виде.

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

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

Форматированный changelog В changelog релизного commit’а имеет смысл включать соответствующий текст из changelog’а пакета, как это делают утилиты (обёртка к, специально предназначенная для этих. В результате можно будет получить предцелей) и ставление об изменениях в очередном релизе пакета, не заглядывая в spec-файл самого пакета.

Правила экспорта С одной стороны, для того, чтобы srpm-пакет мог быть импортирован в git-репозиторий наиболее удобным для пользователя способом, язык правил, согласно которым производится экспорт из коммита репозитория (в форму, из которой можно однозначно изготовить srpm-пакет или запустить сборку), должен быть достаточно выразительным.

С другой стороны, для того, чтобы можно было относительно безбоязненно собирать пакеты из чужих gear-репозиториев, этот язык правил должен быть достаточно простым.

Файл правил экспорта (по умолчанию ) состоит из строк формата « », параметры разделяются пробельными символами.

Директивы позволяют экспортировать:

• любой файл из дерева, соответствующего коммиту;

• любой каталог из дерева, соответствующего коммиту в виде tarили zip-архива;

• unied di между любыми каталогами, соответствующими коммитам.

Вечернее заседание (14.45–19.15) Файлы на выходе могут быть сжаты с помощью gzip или bzip2. В качестве коммита может быть указан как целевой коммит (значение параметра утилиты gear [2]), так и любой из его предков при соблюдении условий, гарантирующих однозначное вычисление полного имени коммита-предка по целевому коммиту.

Правила экспорта из gear-репозитория описаны детально в документации к gear [4].

Основные типы устройства gear-репозитория Правила экспорта реализуют основные типы устройства gearрепозитория следующим образом:

Архив с модифицированным исходным кодом С помощью простого правила « » всё дерево исходного кода экспортируется в один tar-архив. Если у проекта есть upstream, публикующий tar-архивы, то добавление релиза в имя tar-архива, например, позволяет избежать коллизий.

Архив с немодифицированным исходным кодом и патчем, содержащем локальные изменения С помощью двух правил, можно экспортировать всё дерево исходного кода в виде tar-архива с немодифицированным исходным кодом, помеченным тэгом  , и патча, который нужно приложить к дереву с немодифицированным кодом для того, чтобы получить дерево с исходным кодом.

Тэг   должен быть зарегистрирован с помощью утилиты Архив с немодифицированным исходным кодом и отдельными патчами Если дерево с немодифицированным исходным кодом хранится в отдельном подкаталоге, а локальные изменения хранятся в gearиюля репозитории в виде отдельных патч-файлов, то правила экспорта могут выглядеть следующим образом:

Такое устройство репозитория получается при использовании утилиты, предназначенной для быстрой миграции от srpmфайла к gear-репозиторию.

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

Литература [1] Junio C. Hamano, «GIT — a stupid content tracker», [2] Dmitry V. Levin, «gear — Get Every Archive from git package Repository», [3] Дмитрий Левин, Hasher: технология безопасной сборки пакетов // Первая международная конференция разработчиков свободных программ на Протве. Тезисы докладов. М., 2004. С. 28–30.

[4] Sergey Vlasov, «gear-rules — rule le for gear(1)», Вечернее заседание (14.45–19.15) Проект: WINE, EngCom Разработки Etersoft для миграции на Linux и вклад Рассмотрена история развития программного продукта WINE@Etersoft, созданного на базе свободного ПО. Перечислены сопутствующие инструменты и решения, позволяющие упростить процесс разработки, автоматизируя рутинный труд. Рассказано о свободных проектах, созданных при участии компании Etersoft. Свидетельствуется о возможности создания компании, успешно продвигающей популярные решения на базе свободного ПО.

Etersoft изначально была направлена на создание и поддержку полноценной и универсальной среды (операционной системы), которая по своим потребительским качествам не уступала бы системам семейства Microsoft Windows. Понятно, что эта задача включает в себя решение бесчисленного множества проблем, которые, впрочем, по силам решить, если взяться за дело дружно, что так или иначе мы видим на примере разработки свободного ПО в мире и в России.

Начав несколько лет назад с внедрения ALT Linux в сфере бухгалтерского учёта и торговли, мы столкнулись с очевидной проблемой: на компьютерах повседневно используется множество специализированных коммерческих программ, не имеющих свободных аналогов, и не могущих их иметь в силу того, что никто не будет бесплатно создавать правовую базу или обновлять еженедельно бухгалтерскую отчётность.

Таким образом, мы пришли к тому, что массовое внедрение Linux требует в начальный (и довольно длительный) период поддержки работы в нём разнообразных программ для Windows. Было принято решение участвовать в разработке проекта Wine, реализующего WinAPI на Unix-системах, особенно внимательно относясь к проблемам запуска популярных в России программ.

К концу 2005 года мы смогли представить первую коммерческую версию WINE@Etersoft. Была реализована возможность совместной работы программ 1С:Предприятия 7.7 в сети и на терминальном сервере. Хочу отметить, что коммерческие версии часто вызывают возгласы «специалистов»: «ах, они закрыли исходники и нарушили GPL». Стоит сказать, что все наши исправления кода, естественно, открыты, исходники публикуются как в виде патчей, так и в составе исходных rpm-пакетов. Но поскольку WINE@Etersoft состоит из целого ряда программ и файлов, имеющих различные лицензии, для соблюдения прав третьих лиц все подобные файлы вынесены в отдельный пакет, называемый «коммерческой частью», в дополнение к «свободной части», имеющей лицензию LGPL.

Также мы публикуем свободные сборки Wine, выполняемые нами для всех дистрибутивов с нашими патчами.

Хочу отдельно отметить хорошие отношения, сложившиеся у нас практически со всеми отечественными разработчиками коммерческого ПО. Компания Аладдин обеспечила работу сетевых и локальных ключей HASP в WINE. Компания БЭСТ участвовала в исправлении проблем, связанных с использованием БЭСТ 4+ и БЭСТ 5. Проблемы с правовыми системами Гарант и Консультант+ мы исправляли, консультируясь с разработчиками. Компании 1С и ИнфоБухгалтер оказывали психологическую поддержку. Интерес отмечен со стороны практически всех производителей ПО, хотя многие ещё считают, что им «эти 5 % рынка» неинтересны.

Многое пришлось взять на себя. На данный момент мы поддерживаем около трёх десятков дистрибутивов, и где-то столько же программ, работающих в Wine. Службе поддержки приходится отвечать на вопросы настройки ОС, различных сервисов, установки Windowsпрограмм и их настройки. До сих пор производители ПО не готовы взять на себя поддержку пользователей своих программ в Wine, и пользователей обращаются к нам и дополнительно оплачивают поддержку для используемых программ.

Только недавно разработка WINE@Etersoft стала окупаться, рост популярности продукта связан с необходимостью лицензировать ПО на предприятии, повышением готовности Linux как настольной системы к коммерческим внедрениям и улучшением качества самого продукта.

На данный момент WINE@Etersoft — это единственное решение, позволяющее исполнять востребованные в России программы при использовании Unix-платформ, не требующее лицензии на Windows и имеющее адекватную поддержку.

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

Безусловно, успехом мы обязаны и международной команде разработчиков Wine, и компании CodeWeavers, общаясь с сотрудниками которой мы делали свой вклад в Wine.

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

В настоящий момент в WINE@Etersoft сделаны следующие полезные улучшения:

• доступна возможность совместной работы с Windows-программами в гетерогенной сети;

• созданы различные тестовые программы, упрощающие жизнь службе поддержки и администраторам;

• разработан административный режим установки, когда единожды установленное Win-окружение доступно для всех терминальных или сетевых пользователей;

• исправлены проблемы с работой торгового оборудования (сканеров штрих-кода и фискальных регистраторов);

• поддержка сетевых ключей HASP, Smartkey Eutron, Sentinel и программы для их тестирования;

• исправлено множество проблем, мешающих нормальной эксплуатации: реализованы диалоги печати, исправлено управление окнами, работа с буфером обмена, оптимизирована загрузка процессора (более 200 зафиксированных ошибок);

• создана документация на русском языке.

Сейчас ведётся работа по обеспечению поддержки WINE@Etersoft на платформе Solaris благодаря инициативе обратившейся к нам компании Sun Microsystems. Имеются планы по поддержке MacOS.

Ещё нужно добавить, что в процессе работы над WINE@Etersoft был создан или доработан, внедрён ряд дополнительных программных средств:

Система продаж Основанная на открытой CMS Joomla, система продаж, хоть и не является полноценным интернет-магазином, но позволяет клиентам в автоматическом режиме выписывать счёт, оплачивать и получать в электронном виде программные продукты. Имеется поддержка работы с партнёрами и разнообразная внутренняя статистика. Продаваемые продукты имеют уникальный регистрационный код, по которому можно проверить легальность продукта, зайдя на специальную страницу продукта.

Linux CIFS Модуль ядра Linux, обеспечивающий монтирование сетевых файловых ресурсов. После проведения доработки (добавлены дополнительные флаги в системный вызов µ, позволяющие реализовать для Wine NT-семантику при открытии файлов) появилась возможность организовать в гетерогенной сети полноценный совместный доступ к файловым ресурсам, то есть совместная работа Windows-программ, запущенных как в Windows, так и в Linux, стала реальностью. В ходе испытаний в коде модуля CIFS был обнаружен ряд ошибок, которые были исправлены и начаты переговоры по внесению исправлений в основной код.

EterSafe Кроме аппаратных средств защиты (например, HASP-ключей) производители ПО активно применяют методику привязки программ к уникальным характеристикам компьютера. Как правило, это реализовано через низкоуровневое обращение к контрольным суммам BIOS в специальном системном драйвере. Для Linux/FreeBSD был создан системный сервис EterSafe для обеспечения доступа из пользовательского процесса (через сокет) к необходимым уникальным кодам компьютера. Это позволяет реализовать защиту как Windows (в Wine), так Вечернее заседание (14.45–19.15) и Linux-программ. Драйвер имеет стандартный интерфейс и идеология его работы может быть перенесена и на другие ОС.

Транслятор SQL-запросов Так сложилось, что ещё недавно было популярно использовать в качестве СУБД продукт компании Microsoft MS SQL Server. В частности, он необходим для работы SQL-версии программы 1С:Предприятие 7.7, которая у нас очень широко распространена. Чтобы обеспечить возможность полной миграции на свободное ПО, нами спроектирован и разработан транслятор SQL-запросов, решающий пока только частную задачу трансляции запросов из диалекта T-SQL в PortgreSQL и откликов сервера, что позволяет использовать свободную СУБД PostgreSQL на Linux-платформе для работы 1С:Предприятия 7.7.

PostgreSQL не в последнюю очередь был выбран потому, что он предлагается компанией 1С для работы их продукта 1С:Предприятие 8.1, а значит, будет тщательно протестирован и хорошо поддерживаться. К тому же, у нас используются новые типы данных, введённые в PostgreSQL для упрощения совместимости с MS SQL по заказу 1С:

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

Реализован транслятор в виде дополнительного модифицированного ODBC-драйвера PostreSQL, который представляется как ODBCдрайвер сервера MS SQL, и разбирает запросы, обращения к системным таблицам, адаптируя их для Postgres. Таким образом, не требуется вмешательства ни в сам сервер, ни в клиентскую программу.

ODBC-драйвер выполнен в виде DLL-библиотеки, что позволяет использовать данное решение как в Wine, так и в Windows-системах.

Для построения кода разбора входных выражений применяются стандартные средства: лексический анализатор ex и генератор синтаксических анализаторов bison. На производительность транслятор влияет незначительно.

EterBuild EterBuild — это достаточно условное название системы сборки, которая применяется в компании для сборки бинарных пакетов под множество целевых платформ из одного src.rpm. Состоит она из нескольких частей:

, позволяющего собирать rpmпакеты, оформленные в соответствии с правилами ALT Linux, на прочих системах, включая Debian.

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

Поверх этого реализована система eterbuild, которая либо по заказу от системы продаж, либо по расписанию, либо по команде разработчика выполняет сборку пакета для различных указанных систем, причём сборка Linux-пакетов выполняется на одном сервере, с использованием, а для других систем (FreeBSD и Solaris) используются (пока) отдельные машины.

Сама по себе система сборки Eterbuild — удобное решение для разработчиков (коммерческих) программ, которым нужно собирать бинарные пакеты или тестировать собираемость на множестве платформ.

Свободный англо-русский словарь компьютерных терминов EngCom В результате активной работы над переводами свободных программ был создан, пожалуй самый полный, хотя и несколько неформальный словарь компьютерной терминологии, где для каждого английского термина найден более или менее удачный перевод. Данный словарь рекомендуется переводчиками KDE и GNOME, он использовался при переводе таких программ как GnuCash, LyX, Dia, K3b и прочих, он регулярно пополняется и доступен в форматах Таким образом, и инструменты, применяемые в компании, и создаваемые решения свидетельствуют о возможности успешного применения в бизнесе свободных программ.

Вечернее заседание (14.45–19.15) Проект: LSB Infrastructure http://ispras.linux-foundation.org Центр верификации ОС Linux: вклад в развитие стандарта LSB и тестирование Linux платформы В докладе представлены активности российского Центра верификации ОС Linux при Институте системного программирования РАН в области стандартизации и обеспечения надёжности Linux-платформы на примере проектов OLVER (по заказу Роснаук

и) и LSB Infrastructure (по заказу Linux Foundation). Описываются текущие результаты и статус. Отдельное внимание уделяется рассказу о назначении, текущем состоянии и планах развития стандарта Linux Standard Base (LSB) и соответствующей инфраструктуры.

О Центре верификации ОС Linux Центр верификации ОС Linux ( »» ») был создан при Институте системного программирования РАН осенью года при поддержке Федерального агентства по науке и инновациям (Роснаука). Миссия Центра — продвижение платформы Linux путём обеспечения её высокой надёжности и совместимости с помощью открытых стандартов и наукоёмких технологий верификации и тестирования. В деятельности Центра участвуют как специалисты ИСП РАН с многолетним опытом в сфере разработки и контроля качества программного обеспечения, так и молодёжь — студенты и аспиранты ведущих ВУЗов (МГУ, МФТИ и МГТУ им. Баумана).

Стандарт Linux Standard Base (LSB) Важнейшим показателем популярности и полезности операционной системы является количество приложений для неё. Что мешает развитию Linux в этом плане? На момент написания статьи на сайте »» » » зарегистрировано 549 (!) дистрибутивов Linux. И там не учитываются версии, сделанные для внутреннего применения различными компаниями и отдельными энтузиастами. Но что такое Linux с точки зрения производителя приложений? По сути, это комбинация системных компонентов, таких как ядро и библиотеки, которые в совокупности предоставляют интерфейсы прикладного программирования для программистов приложений. Проблема заключается в том, что каждый дистрибутив Linux представляет собой уникальную комбинацию различных версий таких компонентов, что в итоге может означать разные интерфейсы, как по составу, так и по поведению. Поэтому написать приложение, которое будет работать на всех дистрибутивах, да ещё и без перекомпиляции (что важно для многих производителей ПО), может оказаться не таким простым делом. И это серьёзно сдерживает рост числа приложений под Linux. Можно делать разные версии приложений под разные дистрибутивы, но это дорого.

Производители приложений хотят создавать приложения «под Linux», а не отдельно под Red Hat или SuSe.

Именно для решения проблемы обеспечения переносимости приложений между различными Linux было предложено разработать открытый стандарт Linux Standard Base (LSB), суть которого заключается в фиксации состава бинарных интерфейсов и требований к их поведению для некоторого подмножества базовой функциональности Linux, на наличие которой можно рассчитывать в большинстве дистрибутивов.

В настоящее время стандарт имеет версию 3.1 и включает порядка 30 000 интерфейсов из более чем 40 библиотек. Большинство основных производителей дистрибутивов сертифицированы на соответствие LSB.

Проекты Центра по тематике LSB Центр верификации ОС Linux активно вовлечён в LSB-сообщество. Первым проектом Центра в этом направлении был Open Linux VERication (OLVER) — »» »

В проекте был проанализирован текст основной части стандарта LSB Core для около 1500 системных функций Linux, были формализованы требования на поведение этих функций и построены тесты для автоматической проверки дистрибутивов Linux на соответствие этим требованиям.

Результаты проекта OLVER заинтересовали комитет по стандартизации LSB — в тот момент консорциум Free Standards Group (FSG), который предложил ИСП РАН долгосрочное сотрудничество в области построения инфраструктуры использования и развития стандарта LSB, а также разработки технологий автоматизации тестирования и создания собственно новых тестов для Linux. Впоследствии, в результате слияния FSG с OSDL был создан консорциум Linux Foundation и сотрудничество с ИСП РАН было расширено. Проект получил название LSB Infrastructure и на прошедшем в июне 2007 года Linux Foundation Collaboration Summit были представлены результаты его первой фазы:

• Переработана схема и проведена чистка главной базы данных LSB, содержащей всю информацию о стандарте и его окружении.

• Построена первая версия веб-портала LSB-разработчиков — LSB • Выполнен дизайн новой системы LSB-сертификации.

• Разработаны средства автоматизации запуска и визуализации результатов тестирования — LSB ATK/DTK Managers.

• Разработаны две технологии автоматизированного создания тестов для соответствующих уровней качества.

• Разработаны новые тесты для 5 библиотек.

Деятельность ИСП РАН в этом проекте — лишь малая часть усилий мирового сообщества, направленных на решение наболевших проблем переносимости приложений. На фоне наблюдаемого в последнее время роста популярности Linux, LSB получил огромный импульс на саммите Linux Foundation из-за возросшей актуальности, что было подчёркнуто как топ-менеджерами ведущих международных ИТ-компаний, так и простыми инженерами на различных технических заседаниях. Был рассмотрен и одобрен двухлетний план развития LSB, направленный на обеспечение массового его внедрения.

Михаил Гильман, Андрей Михеев, Пётр Михеев Проект: DIFFR http://developer.berlios.de/projects/dir Проект DIFFR — открытая система для моделирования двумерных задач дифракции DIFFR — графическая среда, в которой двумерная задача дифракции на неровной поверхности может быть решена при помощи различных асимптотических и численных методов. Среда содержит набор уже существующих приближенных методов. Предполагается, что новые приближенные методы будут разрабатывать и загружать в систему исследователи-физики. Система позволит как сравнивать различные приближенные методы, так и решать конкретные задачи дифракции при помощи наиболее эффективного в данном диапазоне физических параметров алгоритма.

Введение Двумерные задачи дифракции световых, электромагнитных и звуковых волн на шероховатой поверхности описываются хорошо известным уравнением Гельмгольца с различными дополнительными условиями на границах раздела сред и условиями на поведение поля в бесконечности.

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

В мире имеется большое количество исследователей и научных школ, развивающих свои методы решения двумерных задач дифракции. Однако в силу разнородности существующих алгоритмов и проУтреннее заседание (9.30–14.00) грамм, для решения конкретной задачи оказывается крайне сложно найти подходящий метод, по тем же причинам очень сложно сравнить различные существующие алгоритмы.

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

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

Среда является платформонезависимой, написана на языке Java.

Некоторые понятия предметной области Задача (Task). Задача — это объединение задаваемых входных данных (поверхность и падающее поле), результата (если он посчитан) и текущего алгоритма (вместе с параметрами).

Вычисление. Вычисление состоит в нахождении отражённого поля при помощи приближенного алгоритма при заданных падающей волне и препятствии.

Поверхность (Surface) Поверхность всегда периодическая. Задаётся формой поверхности и проводимостью. Форма поверхности задаётся периодом, параметром и коэффициентами Фурье.

Падающее поле (Impinging eld). Падающее поле — это плоская электромагнитная волна. Задаётся углом к вертикали (в градусах), длиной волны (в сантиметрах), амплитудой и поляризацией Отражённое поле (Reected eld). Это одна из составляющих результата. Состоит из нескольких плоских волн.

Поверхностные токи (Surface current). Это одна из составляющих результата. Комплексная функция от координаты на поверхности.

Изображается в виде двух кривых — модуль и фаза.

Краткое описание интерфейса системы Окно программы делится на две части. Справа находится изображение поверхности и падающего поля. Левая часть состоит из трёх вкладок: Input data, Result и Algorithm.

Вкладка Input data используется для изменения входных данных.

Внутри неё ещё две вкладки — Surface (для изменения поверхности) и Impinging eld (для изменения падающего поля).

Вкладка Result используется для просмотра результата вычислений. Состоит из Reected eld (Отражённое поле), Passed eld (Прошедшее поле) и Surface current (Токи в поверхности). Если выбранный алгоритм не умеет вычислять какую-либо из частей результата, вкладка для неё отображена не будет.

Вкладка Algorithm используется для выбора алгоритма и изменения его параметров.

Состояние. В нижней части окна отображается текущее состояние.

Оно может быть одним из:

завершена нормально Масштаб. В левом верхнем углу изображения поверхности и падающего поля есть надпись + число. Это масштаб изображения — сколько пикселов приходится на единицу измерения (сантиметр).

Возможные действия в системе New task Создать новую задачу, с входными данными по умолчанию.

Текущая задача при этом будет потеряна.

Load task Загрузить ранее сохранённую задачу. Текущая задача при этом будет потеряна.

Save task Сохранить текущую задачу.

Exit Выйти из системы. Текущая задача будет сохранена в файл и автоматически загружена при следующем запуске программы.

Утреннее заседание (9.30–14.00) Start Начать вычисление результата.

Stop Прервать вычисление результата.

Add algorithm Добавить новый алгоритм.

Remove algorithm Убрать ранее добавленный алгоритм.

Текущее состояние проекта Проект опубликован на портале свободного ПО »». В систему загружен первый приближенный метод решения задачи дифракции — асимптотический метод малых возмущений.

Руслан Хихин Москва, ОАО «Концерн Моринформсистема „Агат“»

Проект: ALT Linux, МСВС Опыт использования Linux в ОАО «Концерн В докладе рассмотрен вопросы, связанные с использованием Linux в ОАО «Концерн Моринформсистема „Агат“».

1. Специфика заказов ОАО «Концерн Моринформсистема „Агат“».

2. Доступ к исходному коду ОС — необходимое условие для нормальной разработки.

3. Сертификация средств защиты информации по требованиям безопасности информации.

4. Перспективы и преимущества использования Linux.

Рассмотрены проблемы и перспективы использования Linux на примере использования МСВС и дистрибутивов ALT Linux.

Преамбула • «НПО Агат» имеет богатый опыт разработки собственной аппаратуры и ОС в 1950–1980-е годы. В «НПО Агат» в 1950–1980-е годы разрабатывались собственное математическое обеспечение, которое включало такие программы, как управление задачами, управление памятью, резервирование вычислительных процессов, восстановление вычислительных процессов и задач при сбое и отказе оборудования.

• Неудавшийся опыт применения MS Windows и удачные решения на основе ОС Unix в 1980–1990-е годы.

Начиная с середины 1980-х годов на смену машинам с прошиваемой памятью пришли компьютеры с имеющейся операционной системой. Пришлось отказаться от разработки собственного системного программного обеспечения и перейти на имеющиеся операционные системы.

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

Требования, предъявляемые к ОС для применения на наших заказах Исходя из опыта разработки можно выделить следующие требования, предъявляемые к операционным системам:

1. Возможность модификации исходного кода ОС и его программного обеспечения.

2. Возможность предоставить исходный код для сертификации.

Важным моментом является необходимость сертификации гостехкомиcсией наших программных продуктов. Одним из её требований является предоставление исходного кода наших программ и программ, работающих в наших комплексах. В случае с МСВС это означает просто ссылку на соответствующее решение, а в случае с ALT Linux "—- предоставление её кода и проведение различных мероприятий по доказательству необходимой функциональности, т. е. приравниванию её кода к нашим программам.

3. Масштабируемость решений. Всегда есть вероятность смены платформы применяемых процессоров, их мощности и т. п.

Утреннее заседание (9.30–14.00) 4. Необходимость обеспечения взаимозаменяемости рабочих мест и резервирования. В наших комплексах особенно важно обеспечение взаимозаменяемости вычислительных машин. Большим подспорьем было бы применение различных кластерных решений.

Во многом их применение сдерживается закрытостью для нас исходного кода МСВС и его отставанием от современного уровня Примеры использования ОС Linux в заказах «НПО Агат»

• Особенности наших вычислительных комплексов. Квалификация пользователей.

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

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

– Техподдержка решений в течение 15–20 лет. Важной особенностью наших систем является долгий срок их службы.

По отдельным экземплярам он доходит до 15–20 лет. Такой срок службы изделий требует предусмотреть возможность модификации наших комплексов в процессе службы. Это опять поднимает вопрос об открытости исходного кода операционной системы.

• Применение ОС Linux в тренажёрах.

• Применение ОС Linux на объектах.

Вопросы сертификации С самого начала возникновения «НПО Агат» наши системы сдавались военной приёмке и их программный код подлежал специальной проверке.

В современных условиях была введена Сертификация программного кода Гостехкомиссией РФ. Как известно, МСВС сертифицирована по третьему классу. Но применение только МСВС тормозит принятие современных решений.

МСВС слишком универсальна, а как всякая универсальная система, она всегда будет проигрывать операционной системе, разработанной под конкретную аппаратуру и конкретные условия. Сдача тренажёров показала, что наличие открытого кода у Linux позволяет проходить сертификацию единичных экземпляров вместе с кодом, созданным нами. Такой подход несколько удорожает стоимость получаемых продуктов, но позволяет создавать решения на современном научнотехническом уровне.

Проблемы и перспективы использования Linux в «НПО Агат»

• При рассмотрении возможных перспектив применение Linux позволяет в будущем модифицировать наши проекты и применять такие решения, как резервирование с учётом возможностей новой Samba, применение репликаций PostgreSQL на основе Slony, кластеризации ядра на основе Mosix и т. п.

• Система восстановления работоспособности. Важным моментом является на сегодня разработка системы восстановления на основе Linux, и в частности, на основе применения технологии Утреннее заседание (9.30–14.00) • Применение не-Intel архитектур. На сегодня актуальным становится применение архитектур, отличных от Intel, например, Sparc. При переносе наших программ на новые архитектуры важным подспорьем являются возможности Linux как кроссплатформенной среды: возможность переносить решения на другую архитектуру путём простого перетранслирования проектов.

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

Кроме инфраструктурной части, описывается подсистема преобразования текстов из одного формата в другой с использованием графового представления логической структуры документа.

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

Существующие системы документооборота обычно относятся к одному из следующих классов:

single-source, single-target;

single-source, multi-target;

multi-source, single-target;

multi-source, multi-target.

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

Реализация систем класса «multi-source, multi-target» осложняется тем, что в общем случае речь идёт о преобразовании текста из произвольного формата в произвольный. Однако если ограничиться лишь логической разметкой, представленной в небинарном виде, то для технических текстов задача преобразования становится гораздо проще.

Система Babylon Основными составляющими системы являются преобразователь форматов и хранилище документов (текстов и бинарных приложений к ним) с подсистемой организации документооборота (набором скриптов для предварительной и постпубликационной обработки, а также редактором связей).

Преобразование документов в системе осуществляется в несколько этапов, на каждом из которых текст представляется в своём формате.

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

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

В настоящее время в рамках проекта Babylon реализован цикл преобразования документов, написанных в формате M-K, в HTML. Также имеются наработки по автоматизации построения парсеров и генераУтреннее заседание (9.30–14.00) торов для входных и выходных форматов разметки, которые будут использованы при создании пользовательских средств описания.

Авторы приглашают к сотрудничеству людей, пользующихся «самодельными» форматами логической разметки, и будут рады любой информации о том, как эти форматы устроены и какими средствами обрабатываются.

Проект: Sisyphus Сборочная система sisyphus (giter factory) Сизиф — большой репозиторий пакетов. Согласно статистике на летний период за день появляются 50 новых или обновлённых пакетов. Пересборка каждого пакета требует значительных ресурсов, в том числе временных.

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

Основные недостатки существующей системы следующие:

1. Эта система обновляется посредством публикации srpm. Этот формат содержит снапшот исходных текстов и не позволяет интегрировать разработку с публикацией в репозитории.

2. Трудности групповой разработки. Так как все пакеты приходят в виде srpms, то разработчикам зачастую приходится обмениваться патчами на снапшоты, не учитывая изменения после релиза.

3. Задержки перед публикацией. Эта проблема вытекает из первой.

Так как разарботчик сам создаёт и отправляет srpm в inсoming1, то проходит некоторое время между фактическим релизом и публикацией в репозитории.

4. Сложности публикации. Публикации пакетов происходят с задержками, складывается ситуация, при которой зависимые пакеты от разных разработчиков могут собираться не в том порядке, 1 Точка входа пакетов в репозиторий Sisyphus.

в каком были собраны srpm. Это приводит к нарушению сборочных зависимостей и неудовлетворённым зависимостям в процессе 5. Сохранение обратной совместимости. Многие мантейнеры не имеют возможности всегда пользоваться актуальными средствами в силу разных причин. Соответственно, переход на новые средства будет происходить в течение некоторого периода.

Для решения этих проблем была разработана другая сборочная система.

Прежде всего потребовалось отказаться от srpm как транспорта исходных текстов. В новой системе используется средство получения снапшота исходных текстов. Это даёт возможность более прозрачно получать пакет из дерева разработки.

Сборочную систему условно можно разделить на две части:

Общедоступное хранилище репозиториев ( ) Общее хранилище обеспечивает возможность удобно вести совместную разработку. В можно хранить репозитории своих проектов. А также можно получать анонсы изменений в других репозиториях.

Система публикации пакетов Новая система публикации пакетов интегрирована с общим хранилищем. Таким образом, процесс разработки и публикации становится прозрачным. Для публикации пакета разработчику нужно лишь дать указание сборочной системе с именем git-тега.

Для обратной совместимости существует возможность публиковать пакеты в виде srpm’ов. В этом случае rpm-пакет конвертируется средв git-репозиторий и дальнейшая работа ведётся уже с ствами ним.

Как только указание получено, репозиторий встаёт в очередь на сборку. Все запросы от разных пользователей сериализуются по времени.

Процесс пересборки параллелится по архитектурам, но не по положению в очереди. Такой подход позволяет просто сформировать порядок сборки зависимых пакетов.

После удачной пересборки пакет сразу же публикуется. Следующие пакеты из очереди пересобираются уже на новом публичном репозитории.

Утреннее заседание (9.30–14.00) Проект: RUNA WFE http://sourceforge.net/projects/runawfe Проект RUNA WFE — свободная система управления бизнес-процессами предприятия RUNA WFE — это open source решение по управлению бизнес-процессами, основанное на популярном workow-ядре JBOSS-JBPM. Система ориентирована на конечного пользователя, является платформонезависимой (написана на Java), распространяется под лицензией LGPL.

Характеристики системы:

– графический редактор бизнес-процессов;

– удобный веб-интерфейс пользователя;

– гибкая система определения исполнителей на основе ролей;

– боты для выполнения автоматических заданий;

– возможность интеграции существующих разнородных приложений – простая интеграция с существующими реляционными базами данных;

– система безопасности, позволяющая интеграцию с LDAP/MS – локализация на английский, французский, немецкий, голландский, испанский, итальянский, русский, украинский и китайский языки;

– поддержка операционных систем Windows, Linux, Solaris, FreeBSD.

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

На практике процессный подход на предприятиях реализуют компьютерные системы управления бизнес-процессами, также называемыми workow-системами. Эти системы позволяют быстро разрабатывать и изменять бизнес-процессы предприятия, не меняя кода системы.

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

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

В течение последних лет активно развиваются свободные workowсистемы, они начинают составлять реальную конкуренцию проприетарным системам.

Демонстрация системы Во время доклада предполагается продемонстрировать работу системы и редактора бизнес-процессов как на примерах разработки бизнес-процессов коммерческой организации, так и на примерах разработки и исполнения процессов административного управления госорганизации.

В качестве примеров бизнес-процессов коммерческой организации будут рассмотрены некоторые процессы консалтинговой группы Руна, в качестве примеров административного управления будут рассмотрены процессы, выделенные в рамках пилотного проекта по переводу Администрации г. Алексин Тульской области на стандарт ISO/IEC 26300:2006.

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

Для работы с заданиями в системе предусмотрен компонент «Task list». Он содержит очереди поступивших заданий, сортировки и фильУтреннее заседание (9.30–14.00) тры. Графические формы заданий показываются при помощи компонента «Проигрыватель форм».

Ядро системы содержит набор определений бизнес-процессов и набор выполняющихся экземпляров бизнес-процессов.

Для просмотра состояний экземпляров бизнес-процессов в системе предусмотрен административный интерфейс.

Графический редактор бизнес-процессов является отдельным приложением, он позволяет создавать графы бизнес-процессов, задавать роли, переменные и графические формы для исполнителей заданий.

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

Краткая история проекта Проект начался в сентябре 2003 года. В консалтинговой группе Руна система RUNA WFE эксплуатируется c июля 2005 г.: В настоящее время количество пользователей системы — около 600, одновременно работают с системой до 200 пользователей. Также система используется OpenSource-сообществом в различных странах — с портала sourceforge на дату 28 июня 2007 г. произведено 17 409 скачиваний системы.

Проект RUNA WFE стал дипломантом конкурса Java-технологий, проводившимся корпорацией Sun Microsystems при официальной поддержке Министерства информационных технологий и связи РФ, также проект получил Honorable Mentions статус на конкурсе JBoss Innovation Award в двух категориях: «Управление бизнес-процессами»

и «Хранение информации».

Литература и ссылки 1. OnLine demo системы доступно по адресу:

2. Сайт проекта: »»

3. Что такое системы управления бизнес-процессами: А. Михеев, М. Орлов. Цикл статей: «Перспективы workow-систем».

Проект: VoxForge Синтез и распознавание русской речи с открытыми В докладе будет рассмотрена деятельность по поддержке русского языка в открытых программных пакетах CMU Sphinx и Festival. Основное внимание будет уделено проблеме создания открытых речевых баз и вариантам их использования.

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

1. Синтез речи. В довольно широком смысле эта проблема решена, речь синтезаторов почти неотличима от речи обычного человека. Проблемы остаются только в области синтеза эмоциональной 2. Управление машиной с помощью команд. В целом, это решённая задача. Проблемы появляются только при наличии помех или необходимости проявления интеллекта машиной.

3. Диктовка связного текста. Эта задача в общем случае не решена, но значительные успехи в этой области имеются.

Утреннее заседание (9.30–14.00) Нужно учитывать, что идеала тут достичь сложно, даже человек не идеален в распознавании и синтезе речи. В некоторых областях машина распознаёт даже лучше, например, приведём такую таблицу из [1]:

Область речи Таблица 12.1: Сравнение числа ошибок человека и компьютера на сходных задачах В отличие от подхода с глубоким изучением особенностей речи, требующего работы высококвалифицированных специалистов, в настоящее время преимущественно накапливаются огромные базы данных речи, которые затем обрабатываются статистическими методами. Некоторое знание языка при данном подходе необходимо, но требования значительно более слабые. Возникают трудности совсем иного рода — огромный размер баз данных. Современная база для синтеза — порядка 30 часов речи одного диктора, для распознавания — 140–150 часов речи 1 000 человек.

Системы распознавания и синтеза с открытым кодом, в том числе и от Microsoft (проект HTK), доступны для использования и изучения. Практикуются автоматические методы обучения (создание модели марковских процессов, деревьев решений, взвешенных автоматов и нейронных сетей).

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

Таким образом, основная работа состоит в сборе больших баз данных, ценность которых огромна. Такие базы позволяют:

– создавать синтезаторы и системы распознавания;

– сопоставлять различные методы создания речевых систем;

– изучать особенности языка;

– свободные базы обладают ещё одним преимуществом — их можно модифицировать и пополнять.

Перечислим проекты, посвящённые речевым технологиям:

• система для разработки синтезаторов Festival [2];

• система распознавания речи CMU Sphinx [3];

• ресурс VoxForge [4] посвящён сбору речевых баз. Текущая база русского языка содержит 10 дикторов по 200 предложений, 2,5 часа речи. На тестовом наборе данных точность распознавания 80 %. Английская база — 15 часов речи;

• синтез русской речи — проект FestLang [5], посвящённый и синтезу русской речи. Предлагается база данных для синтеза речи и готовый синтезатор.

В настоящий момент работа идёт по следующим направлениям:

– разработка DSP-алгоритма с хорошими возможностями моделирования;

– интонационная база русского языка для синтезатора;

– сбор базы для распознавания слитной русской речи;

– диалоговая система по управлению рабочим столом GNOME, в рамках Google SoC развивается проект gnome-voice-control.

Литература [1] Huang, Xuedong. Spoken Language Processing. Prentice Hall PTR, [2] Утреннее заседание (9.30–14.00) [3] [4] [5] [6] Зализняк А. А. Грамматический словарь русского языка.

Рената Пожидаева Томск, Томский государственный университет Русификация речевого синтезатора eSpeak Несмотря на существование развитых OpenSource-синтезаторов, таких как Festival, Flite и FreeTTS, создание русскоязычного синтезатора речи долгое время оставалось проблемой. До недавнего момента было известно две разработки, способных функционировать в среде GNU/Linux — закрытый ru_tts и попытка русификации Festival, проводимая в МГУ. Последний проект затруднительно использовать на практике вследствие недостатков самого Festival.

Синтезатор eSpeak [1] построен на основе универсальных алгоритмов, которые в принципе можно использовать для обработки текстов любого языка. На практике работа программ синтеза речи состоит из двух этапов: преобразование текста в последовательность звуков некоторого языка и получение звукового сигнала на основе последовательности звуков. Фонетические составляющие речи в eSpeak делятся на три группы: гласные, глухие согласные и звонкие согласные. Гласные генерируются из опорных последовательностей, каждая из которых определяет вершину форманты. Меняя частоту этой форманты, можно изменять звучание гласной, что позволяет добиться звуков, специфичных для любого языка. На практике оказалось, что подбирать параметры генератора вручную, сравнивая получившийся результат со звучанием некоторой гласной буквы, очень сложно. Поэтому приходится использовать специальную программу, поставляемую разработчиком, анализирующую запись гласной буквы и подбирающую параметры автоматически. Звонкие согласные целиком синтезируются алгоритмами eSpeak на основе подобранных параметров. Глухие согласные воспроизводятся на основе записанных и очищенных звуков человеческого голоса без какой-либо дополнительной обработки. В некоторых случаях звонкие согласные можно получить смешиванием методов генерации гласных и глухих согласных.

На основе этих алгоритмов в синтезаторе eSpeak реализована поддержка нескольких европейских языков и диалектов. Для реализации поддержки русского языка потребовалось формализовать правила разложения русского текста на фонетические составляющие и подобрать параметры алгоритмов для получения гласных и согласных звуков. Преподаватель филологического факультета Д. А. Катунин составил эти правила. Они оказались связанными с позицией буквы в слове, окружением другими буквами, а также с ударением. Учёт расстановки ударения решается путём использования заранее заготовленного словаря. Проведены работы по реализации всех этих алгоритмов для поддержки русского языка. В данное время синтезатор удовлетворительно озвучивает некоторые русские тексты.

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

Работа синтезатора eSpeak реализована в среде GNU/Linux, в настоящее время ведётся перенос его в ОС Windows. Подготовлена его RPM-версия для дистрибутивов ALT Linux со словарём ударений.

К числу достоинств синтезатора «eSpeak» нужно отнести его гибкую организацию. Алгоритмы реализованы в виде iso-библиотеки и выполнена утилита для вызова синтезатора из командной строки. При желании функция синтеза речи может быть использована в любом приложении путём подключения библиотеки. Получаемый звуковой сигнал может быть воспроизведён с помощью библиотеки PortAudio или сохранен в wav-файле.

Литература [1] J. Duddington. ESpeak text to speech [Электронный ресурс] / Sourceforge.net; ред. — Электрон. Дан. — UK: J. Duddington, 1995. — Режим доступа: http://espeak.sourceforge.net/, свободный.

Утреннее заседание (9.30–14.00) Павел Сёмин Обнинск, Обнинский Государственный Технический Проект: libocr libocr: ядро системы распознавания текста для В докладе рассказывается о библиотеке libocr — ядре системы распознавания текста, предназначенной для использования в свободных ОС. Акцент делается на вопросах, возникающих при практическом использовании библиотеки. В частности, большое внимание уделяется проблеме адаптации системы к новым языкам распознавания.

Когда в жарких спорах о неоспоримых преимуществах свободного программного обеспечения заходит речь о системах распознавания документов, бойцы краснознамённой добровольной народной дружины имени Ричарда М. Столлмена неожиданно теряют свой пыл, грустнеют и стараются побыстрее сменить тему разговора. Попробуем разобраться в том, почему сторонникам свободного программного обеспечения хвалиться в этой области пока что нечем.

Системой распознавания текста называют программное обеспечение, выполняющее функции по преобразованию изображения рукописного, рукопечатного (т. е. написанного от руки, но печатными буквами) или печатного текста в один из текстовых форматов, пригодных для редактирования. Первые системы распознавания появились в 30-х годах прошлого века и представляли собой хитроумные устройства, принцип работы которых был основан на законах геометрической оптики. С тех пор за подобными системами закрепилось название Optical Character Recognition (сокращенно — OCR), хотя очевидно, что и принципы работы современных систем распознавания совсем другие, и распознаются не просто отдельные символы, а целые документы со всевозможными таблицами, формулами, рисунками и т. п.

Если с системами распознавания документов для Windows всё в порядке (тут безоговорочным лидером является ABBYY FineReader), то ситуация со свободными ОС выглядит удручающей. Во-первых, свободных систем распознавания документов как таковых в природе не существует (вполне возможно, что они просто неизвестны автору) — есть только системы распознавания текста. В чем разница? Все очень просто — если система распознавания документов работает с документами, которые помимо текста содержат рисунки, таблицы, формулы и другие нетекстовые элементы и корректно их обрабатывает, то система распознавания текста воспринимает только текст, а нетекстовые элементы, если они есть, в лучшем случае игнорирует, а в худшем — пытается интерпретировать их как текст. На самом деле, это не такой уж серьезный недостаток — множество «документов-из-реального-мира» можно ввести в компьютер и с помощью системы распознавания текста. Плохо другое (оно же во-вторых) — большинство проектов по созданию свободной системы распознавания давно и успешно заброшены. Наиболее известными проектами по созданию свободной OCR являются:

ClaraOCR GOCR HOCR Kognition Ocrad ocre OCRchie OOCR Tesseract Проект «Открытый код»

Почему более крупные и сложные проекты выживают и успешно развиваются, а системам распознавания все время «не везёт»? Одна из причин этого — высокая «наукоёмкость» задачи, из-за чего получить приемлемые результаты не удаётся ни с первой, ни со второй, ни с третьей попытки — в итоге у разработчика опускаются руки и проект отправляется на свалку истории. Как ни странно, получить точность распознавания порядка 90–95 % на ограниченном классе документов относительно легко, но такой точности совершенно недостаточно для практического использования системы. Доведение этого параметра до приемлемого значения в 99 % требует по-настоящему титанических усилий.

Теперь, ознакомившись с текущим состоянием дел в области разработки систем распознавания для свободных ОС, перейдём непосредственно к теме доклада — библиотеке libocr. Если быть предельно кратУтреннее заседание (9.30–14.00) ким, то библиотека libocr представляет собой ядро системы распознавания текста, которое специально проектировалось для использования в свободных ОС. Основные отличия libocr от других систем распознавания текста состоят в следующем:

• объектно-ориентированный API на языке C, что позволяет использовать библиотеку из различных языков программирования;

• добавление нового языка распознавания происходит без модификации библиотеки и не требует большого объёма специальных • изначальная поддержка UNICODE;

• лицензия LGPL.

Список внешних зависимостей библиотеки libocr минимален, благодаря чему не должно возникать больших проблем с её переносом на различные ОС:

• библиотека GLib версии не ниже 2.10.0;

• библиотека libti.

Чтобы показать, насколько проста в использовании библиотека libocr, обратимся к небольшому примеру:

Хорошо видно, что непосредственно за распознавание изображения отвечает единственная функция две функции используются для загрузки изображения и сведений о языке распознавания:

µ. Остальной код отвечает за обработку ошибок и освобождение ресурсов, а значит, может быть существенно упрощён при использовании libocr из более высокоуровневого языка программирования (например, C++).

Каким образом происходит распознавание изображения? В составе ядра системы распознавания можно выделить три функциональных блока, работающих строго последовательно:

• блок предварительной обработки;

• блок сегментации;

• блок распознавания.

Блок предварительной обработки решает задачу определения угла наклона строк текста на изображении документа и поворота изображения таким образом, чтобы строки текста располагались строго горизонтально.

Блок сегментации предназначен для определения границ отдельных символов, их пространственного положения и степени их логической взаимосвязи. Результатом работы блока сегментации является граф, описывающий логическую структуру документа. Узлами графа являются отдельные структурные элементы исходного документа, а дуги задают пространственные отношения между ними. Свойства структурУтреннее заседание (9.30–14.00) ных элементов описываются в виде атрибутов, связанных с соответствующими узлами графа.

Блок распознавания выполняет функцию по классификации изображений отдельных символов. На вход блока поступает растровое изображение символа, а на выходе формируется код символа в кодировке UNICODE. Для классификации изображений используется предварительно обученная искусственная нейронная сеть (персептрон с двумя активными слоями нейронов).

Что нужно сделать для добавления нового языка распознавания?

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

• изображения, входящие в обучающую выборку, должны быть максимально близкими к тем, которые будут предъявляться нейронной сети во время работы, поэтому лучше, если в выборку будут входить реальные отсканированные изображения;

• не имеет смысла добавлять в выборку несколько очень похожих изображений одного и того же символа — это замедлит процедуру обучения, но практически никак не скажется на качестве распознавания.

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

На данным момент была проведена серия экспериментов по обучению системы распознавания для работы со строчными символами русского алфавита. В некоторых случаях точность распознавания на ограниченном классе предъявляемых документов составляла 99,8 %.

Проект: OpenVZ Развёртывание и поддержка мультисервисных серверов с применением виртуализации OpenVZ.

Общие вопросы и вопросы применения на базе Debian Некоторое время назад SWSoft лицензировала ядро своего решения для виртуализации Virtuozzo под названием OpenVZ на условиях GPL2, что позволяет использовать его в некоммерческих и бюджетных проектах.

OpenVZ — это реализация технологии виртуализации на уровне операционной системы, которая базируется на ядре Linux. OpenVZ позволяет на одном физическом сервере запускать множество изолированных копий операционной системы, называемых Виртуальные Частные Серверы (Virtual Private Servers, VPS) или Виртуальные Среды (Virtual Environments, VE).

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

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

В докладе описывается опыт решения задачи развёртывания и поддержки серверов, обеспечивающих выполнение различных сервисов на одной физической машине с разделением доступа при помощи OpenVZ.

Освещаются общие вопросы организации подобных систем, преимущества, недостатки, часто встречающиеся проблемы и архитектурные ошибки, демонстрируются способы решения типовых задач администрирования. Практические примеры показаны на базе дистрибутива Debian GNU/Linux.

Утреннее заседание (9.30–14.00) Проект: Xen, Red Hat Cluster http://xensource.com/xen/ Опыт объединения технологий виртуализации и кластера высокой доступности В данном докладе рассказывается об опыте развёртывания и тонкостях применения технологий кластеризации и виртуализации в рамках одной системы. В докладе описывается место и особенности применения обоих технологии, а также требования к аппаратной части.

В последнее время было достаточно много разговоров о технологиях виртуализации, об их достоинствах и недостатках. Чаще всего говорится о разделении ресурсов, изоляции служб и абстрагировании их от аппаратной части, и о недостатках: накладных расходах на виртуализацию и общем усложнении системы.

Виртуализация удобна тем, что позволяет создать контейнер с выделенными ресурсами (процессором, памятью, дисковым пространством, сетевыми интерфейсами). Все эти ресурсы удобно выделить изолированной службе, которая будет решать определённую задачу, такую как СУБД или http-сервер со всем ему необходимым.

Благодаря тому что контейнер не привязан к аппаратной части, теоретически его возможно запускать на некотором множестве серверов, что будет абсолютно прозрачно для пользователей этой службы. Конечно, чтобы это работало на практике, нужно выполнение некоторых условий.

• Однородность сетевой структуры. Обычно это означает, что физические сервера должны быть в одной подсети, но это может быть обеспечено и другими средствами.

• Физический сервер должен «уметь» исполнять код контейнера (например, невозможно запустить контейнер, созданный для архитектуры x86_64 на сервере с архитектурой i586).

• Контейнер должен иметь возможность добраться до своих данных. Эта проблема может быть решена разными способами. Например файловая система контейнера может находиться на NFS или на общем хранилище SAN.

При выполнении этих условий контейнер может быть запущен на группе серверов, но при этом должны существовать средства управления запуском/остановкой/перемещением контейнеров. Для этих цели возможно применять кластер высокой доступности.

Кластер рассматривает контейнер как службу (в понимании кластера) и он их запускает, останавливает, проверяет состояние. В случае сбоя одного из серверов или его выключения по каким-то другим причинам, кластерное ПО автоматически запускает контейнеры на имеющихся узлах. Также кластерное ПО может следить за доступом к общему хранилищу данных.

Автором был развернут такой кластер, и сейчас ведётся разработка технологии быстрого развёртывания подобных кластеров для широкого спектра аппаратных конфигураций.

В качестве технологии виртуализации был использован xen. Xen — многоплатформенная, свободная технология паравиртуализации, поддерживающая и полную виртуализцаию (на некотором аппаратном обеспечении). Паравиртуализация — это тип виртаулизации, в котором каждая виртуальная машина имеет своё специально модифицированное ядро ОС, взаимодействующее с гипервизором, для доступа к абстрагированному оборудованию и других целей. Причём в этой модели нет хост-системы как таковой. Все экземпляры запущенных ОС исполняются внутри виртуальных машин, но только одна из них, Domain0, имеет по умолчанию полный доступ к аппаратной части, остальные имеют доступ только к определённым устройствам. Гипервизор — это фактически операционная система, которая распределяет ресурсы между виртуальными машинами, которые исполняются как программы в обычных ОС. Гипервизор загружается до виртуальных машин, запускает Domain0, который, в свою очередь, через запросы к гипервизору управляет другими виртуальными машинами. Обычно Domain0 является минимальной системой с Linux, в которой присутствуют только драйверы, средства управления жёсткими дисками и файловыми системами, средства удалённого администрирования и, в нашем случае, кластерное ПО.

Утреннее заседание (9.30–14.00) В качестве кластера высокой надёжности использовался Red Hat Cluster. Это комплексный программный продукт, состоящий из компонентов:

• сman — Cluster MANager. Базовый компонент, отвечающий за членство узлов в кластере, т. е. отслеживающий вход/выход узлов в кластере и обеспечивающий взаимодействие между ними.

• Dlm — distributed lock manager. Библиотека + модуль к ядру Linux, занимающийся кластерными блокировками, используется почти всеми компонентами кластера.

• Fence — система отключения питания от узлов, физически отрезает узел от кластера в случае сбоя на нём.

• Clvmd — Cluster LVM Daemon. Демон, занимающийся управлением логическими томами на общем хранилище кластера. Ключевой компонент, так как диски виртуальных машин удобно хранить в LVM, этот демон решает многие проблемы, связанные с синхронизацией LVM между узлами.

• GFS — global le system. Кластерная файловая система, позволяет нескольким узлам иметь общие данные.

• Rgmanager Resource Group manager. Опять же ключевая программа, она заниматься непосредственно управлением службами.

На основе этих технологий была построена следующая система.

Аппаратное обеспечение:

• 8 узлов (2 двухядерных процессора 4 Гб памяти) — непосредственно узлы кластера.

• Общее хранилище данных, соединённое с узлами по FiberChannel • 2 балансировщика нагрузки.

• Сервер резервного копирования.

На жёстких дисках узлов храниться только dom0 и xen, все остальные данные на общем хранилище. Весь объем хранилища (несколько Tb) разделён при помощи LVM, на котором выделены тома для виртуальных машин и их данных. Создано несколько виртуальных машин, которые решают прикладные задачи (веб-серверы, почтовые серверы, СУБД), эти виртуальные машины запускаются кластерным ПО на разных узлах кластера. Балансировщики находятся в режиме failover, все запросы из внешнего мира они перенаправляют на соответствующие IP-адреса во внутренней сети кластера, принадлежащие виртуальным машинам. На сервере резервного копирования запущено 2 виртуальные машины, одна из которых собственно осуществляет резервное копирование, а на второй запущена система мониторинга.

В результате получается гибкая и надёжная система, обеспечивающая удобство обслуживания, отсутствие необходимости останавливать службы при изменении конфигурации и функционирование при отказе до 50 % аппаратного обеспечения.

Проект: T-Sim Библиотека шаблонных классов С++ для поддержки Современные высокопроизводительные вычисления немыслимы без использования параллельных вычислений. В последние годы массовое использование многоядерных процессоров ставит перед большинством программистов задачи, которые ранее решались лишь узким кругом специалистов в суперкомпьютерных центрах. В библиотеке T-Sim программисту предоставляется набор шаблонных классов и функций С++, который предоставляет возможность создавать сравнительно компактный код, переносимый между различными мультикомпьютерами (многоядерные процессоры, SMP-системы, вычислительные кластеры, метакластеры). Основа библиотеки — инкапсуляция ряда понятий (таких как «переменная», «функция» и некоторых других), необходимых для написания программ, близким по стилю к программам на функциональных языках. Предлагается также ряд шаблонных функций, реализующих наиболее часто применяемые методы распараллеливания вычислений.

T-Sim представляет собой библиотеку шаблонных классов С++, разработанную и реализованную на основе концепции Т-системы[1].

Утреннее заседание (9.30–14.00) Отличительными особенностями как T-Sim так и OpenTS — современной реализации Т-системы — является использование бесконфликтной модели вычислений на основе чистых (не имеющих побочных эффектов) функций и «неготовых значений» как средства синхронизации доступа к результатам вычислений. При попытке доступа к данным, находящимся в «неготовой переменной» из потока потребителя, проверяется, вычислены ли уже эти данные потоком-производителем. Если да, то поток-потребитель продолжает работу, если нет, то работа потока-потребителя приостанавливается до тех пор, пока какой-либо поток не вычислит данные для неготовой переменной.

Библиотека T-Sim состоит из набора заголовочных файлов и статически связываемой библиотеки С++. При написании программы пользователь определяет «неготовые значения» при помощи соответствующих шаблонных классов. «Т-функции» — чистые функции, которые среда выполнения программ может вычислять параллельно, декларируются программистом при помощи макросов. Библиотека T-Sim позволяет осуществлять распараллеливание вычислений, передавая вызовы «т-функций» для вычисления либо в отдельные потоки, либо на удалённые компьютеры (другие узлы вычислительного кластера). Механизм распределения нагрузки между узлами вычислительного кластера может быть определён пользователем. Предоставлен набор классов-стратегий на основе которых программист может сконструировать алгоритм выравнивания нагрузки из готовых «запасных частей».

T-Sim — высокоуровневое средство параллельного программирования. В отличие от общепринятых сейчас средств создания параллельных программ, таких как Message Passing Interface (MPI) и Posix Threads, T-Sim позволяет создавать достаточно компактные, простые в поддержке программы. По сравнению с аналогичными высокоуровневыми средствами T-Sim обладает, на сегодняшний день, следующими основными преимуществами:

• Использование среды исполнения программ С++, допускающих низкоуровневую оптимизацию.

• Переносимость программ — однажды написанная, программа на T-Sim может работать как на многоядерном процессоре, многопроцессорной системе, так и в системе с распределённой памятью — вычислительном кластере, федерации нескольких вычислительных установок (мета-кластере).

• Существующая реализация библиотеки поддерживает работу в гетерогенной среде за счёт использования сериализации данных на основе XML. При этом при обмене данными между однотипными узлами вычислительной среды могут использоваться более эффективные механизмы обмена данными.