CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
22.11.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Desktop
Internet
Internet-серверы
Безопасность
Бизнес/Офис
Игры
Мультимедиа
Наука
Операционные системы
Программирование
СУБД
Создание веб-сайтов
Утилиты

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Движение Open Source

Открытые стандарты и новые формы международного сотрудничества

Труды Института системного программирования РАН

Страницы: предыдущая :: 1 :: 2 :: 3 :: следующая

4. Международное сотрудничество в области открытых стандартов

4.1. The Austin Group

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

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

Стандартизация интерфейса между прикладными программами и операционной системой появилось как естественное решение данной проблемы. Предпринималось множество попыток стандартизации программного интерфейса операционных систем семейства UNIX, но наибольшее признание получил стандарт POSIX (Portable Operating System Interface for Computing Environment). Работа над этим стандартом началась в 1984 году в рамках образованного под эгидой IEEE CS комитета по стандартам для переносимых приложений (Portable Application Standards Committee, PASC).

Первая версия стандарта POSIX, имевшая официальное название IEEE Std 1003.1, вышла в 1988 году. Она содержала требования к функциям прикладного интерфейса операционной системы на языке программирования C. В течение последующих нескольких лет стандарт немного доработали, устранили выявленные неточности и в 1990 году выпустили вторую редакцию IEEE Std 1003.1-1990, которая была принята в качестве международного стандарта ISO/IEC 9945-1:1990.

Затем основная работа PASC проводилась в подкомитетах и заключалась в разработке дополнений к базовому стандарту. Этот этап развития стандарта POSIX завершился выпуском очередной редакции IEEE Std 1003.1-1996, в которую вошли дополнения IEEE Std 1003.1b-1993 (Realtime Extension), IEEE Std 1003.1c-1995 (Threads) и IEEE Std 1003.1i-1995 (Technical Corrigenda to Realtime Extension). Эта редакция также была утверждена в качестве международного стандарта ISO/IEC 9945_1:1996.

Среди других организаций на поле стандартизации UNIX-подобных систем следует выделить The Open Group, образованную в 1993 году посредством слияния X/Open и Open Software Foundation (OSF). В том же году The Open Group получила от Novell права на торговую марку UNIX и начала работу над единой спецификацией UNIX (Single UNIX Specification, SUS). Эта спецификация включала в себя стандарт POSIX и дополняла его достаточно большим набором функций, являющихся устоявшейся практикой среди UNIX-подобных систем.

Ключевое событие в истории стандартизации UNIX-подобных систем произошло в сентябре 1998 году, когда была образована The Austin Group - рабочая группа по развитию совместного стандарта IEEE Std 1003, ISO/IEC 9945 и Single UNIX Specification. Результатом работы этой группы стал выпуск новой, единой версии всех этих стандартов IEEE Std 1003.1-2001, ISO/IEC 9945:2001 и базовой части Single UNIX Specification version 3.

Наиболее важным новшеством в принципах работы The Austin Group стал переход к открытым методам развития стандарта POSIX. Представитель любой коммерческой компании или учебного заведения и любое частное лицо может стать членом The Austin Group и принимать активное участие в процессе стандартизации. Единственное, что для этого требуется сделать - это подписаться на электронный список рассылки The Austin Group [16].

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

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

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

Важную роль в деятельности The Austin Group играет председатель группы (в настоящее время - Andrew Josey из The Open Group). Он отвечает за организацию жизнедеятельности группы, проведение телеконференций, подготовку протоколов и других документов группы. В сфере его ответственности также лежит организация взаимодействия группы с формальными органами ISO и IEEE, необходимого для принятия обновленных версий стандарта как официальных международных стандартов.

Текст стандарта Single UNIX Specification является общедоступным на сайте The Open Group [17]. Тексты стандартов IEEE Std 1003 (POSIX) и ISO/IEC 9945 распространяются согласно традиционным принципам распространения стандартов этих организаций. Но так как IEEE Std 1003 (POSIX), ISO/IEC 9945 и Single UNIX Specification являются единым стандартом, то недоступность текстов с логотипами IEEE и ISO/IEC не сильно ограничивает возможности пользователей.

Открытость The Austin Group для всех заинтересованных сторон влечет за собой множество преимуществ. Свободная доступность текста стандарта ведет к большему признанию и распространению стандарта в среде разработчиков приложений для UNIX-подобных систем. Большее количество читателей стандарта приводит к более быстрому обнаружению скрытых проблем в стандарте, неочевидных непосредственно рабочей группе. Возможность свободного участия разработчиков операционных систем и разработчиков приложений в обсуждениях рабочей группы по интерпретации требований стандарта и по путям его дальнейшего развития позволяет более полно учитывать мнения различных сторон и скорее находить общепризнанные решения.

4.2. Free Standards Group

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

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

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

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

По этим причинам сообщество Linux инициировало работу по стандартизации базовых интерфейсов операционной системы на бинарном уровне. Для этого в 1998 году была образована некоммерческая организация Free Standards Group, под эгидой которой началась разработка стандарта Linux Standard Base (LSB). Деятельность по созданию стандарта поддержали Линус Торвальдс, Брюс Перенс, Эрик Раймонд, несколько поставщиков дистрибутивов Linux, разработчики приложений, члены Linux International, а также Джон Хаббард из проекта FreeBSD [18].

Работа Free Standards Group по разработке стандарта LSB следует духу открытости, принятому в среде программного обеспечения с открытым кодом, каким является ОС Linux. В этом вопросе LSB Workgroup (рабочая группа по разработке стандарта LSB) не ограничивается открытостью процесса работы рабочей группы и текста стандарта. В отличие от The Austin Group, в LSB Workgroup открыты все внутренние средства и инструменты по разработке стандарта, а также тестовые наборы для проверки на соответствие.

Стандарт LSB генерируется на основе информации о составе интерфейсов, хранящейся в базе данных, и описаний этих интерфейсов из отдельных SGML-файлов. На основе этой же базы данных генерируются дополнительные инструменты, упрощающие разработку приложений на основе стандарта. И база данных, и скрипты, участвующие в генерации, доступны всем на сайте Free Standards Group.

Рабочий процесс LSB Workgroup имеет очень много общего с процессом The Austin Group. Обсуждения основных вопросов ведутся в списке рассылки рабочей группы [19], еженедельно проводятся телеконференции, на которых обсуждаются ключевые вопросы. Два раза в год проводятся двух-трехдневные личные встречи участников рабочей группы, посвященные вопросам развития стандарта.

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

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

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

Являясь некоммерческой организацией, Free Standards Group получает поддержку от многих крупных организаций, заинтересованных в успешном развитии операционной системы Linux. В число активных членов Free Standards Group входят все ключевые производители дистрибутивов ОС Linux (Red Hat, Novell/SuSe, Mandriva, Debian, Red Flag), компании-разработчики приложений (MySQL, RealPlayer), а также такие компании, как IBM, Intel, HP, Oracle, AMD и т.д.

Free Standards Group уделяет достаточно много внимания вопросам международного сотрудничества. Во всех частях света она старается организовать неформальные центры поддержки и распространения стандарта LSB. В Китае в качестве такого центра выступает China Electronics Standardization Institute (CESI), в Южной Корее - Electronics and Telecommunications Research Institute (ETRI), в Сингапуре - Center for International Cooperation for Computerization (CICC), в Японии - Japan Linux Association (JLA), в России - Институт Системного Программирования РАН (ИСП РАН).

4.3. Стандартизация Linux: сотрудничество с The Austin Group и Free Standards Group

Сотрудничество ИСП РАН на поле стандартизации ОС Linux началось в середине 2005 года. На первом этапе проводилась формализация требований стандарта LSB к поведению компонентов ОС Linux, а также разрабатывался систематический тестовый набор OLVER [20], проверяющий различные реализации на соответствие требованиям этого стандарта LSB. Процесс формализации требований и разработки тестового набора базировался на технологии UniTESK [21, 22].

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

Для обсуждения замечаний Free Standards Group предоставляет доступ к базе данных (для проекта выбрана Bugzilla [23] - система управления ошибками, распространяемая свободно с открытым кодом), в которой фиксируются все действия по обработке замечаний к стандарту [24]. Дискуссия, которая возникает при обсуждении замечаний, принятые решения и отчет о внесенных изменениях в текст стандарта - все это фиксируется в базе данных.

В настоящее время на сайте проекта опубликовано 44 замечания к стандарту LSB [25], по которым подготовлены и отправлены сообщения. Эти замечания приняты к обработке, 23 из них уже обработаны, и соответствующие изменения будут внесены в следующие версии стандартов или отражены в документах, описывающих известные дефекты стандарта.

12 опубликованных замечаний описывают обнаруженные в стандарте опечатки - такие замечания обрабатывались и исправлялись в течение нескольких дней. 13 замечаний относятся к противоречиям в стандарте (например, константам, определяющим скорость работы терминала, в разных частях стандарта соответствовали разные значения 2). 19 замечаний выявляют неточности или же ошибки в стандарте (например, при описании функции inflate() использовалась константа Z_BLOCK, которая нигде в стандарте не определялась 3, или же неправильное определение констант, описывающих тип мьютекса в тексте стандарта и в заголовочных файлах 4). При обработке таких замечаний часто начинались дискуссии с участием других членов рабочей группы, решения по некоторым замечаниям до сих пор не приняты.

При обработке замечаний в The Austin Group база данных для фиксации обсуждений и действий не используется, обсуждение происходит в рассылке рабочей группы, а принятые решения фиксируются в официальном документе, содержащим замечания к стандарту. Этот документ находится в свободном доступе и периодически обновляется [26]. На сайте проекта опубликовано 15 замечаний к стандарту POSIX [27], об этих замечаниях сообщено в The Austin Group.

Все замечания приняты, но окончательное решение по замечаниям пока не принято.

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

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

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

Разработанный тестовый набор также находится в открытом доступе на сайте проекта [20]. В ходе отладки тестового набора на разных реализациях обнаруживались отклонения реализаций от требований стандарта, а также дефекты стандарта, не замеченные на этапе анализа и разработки спецификаций. Сообщения о найденных несоответствиях поведения реализации требованиям стандарта отсылались разработчикам библиотек и дистрибутивов. Процесс обработки ошибок в реализациях в целом аналогичен процессу, применяемому при обработке замечаний к стандарту LSB. Так, например, для обработки ошибок в проекте glibc [28] также используется Bugzilla [29].

В качестве примера ошибок, обнаруженных в ходе разработки тестового набора, можно привести ошибку в текущей версии glibc (glibc-2.4): реализация функции insque() не соответствовала стандарту POSIX. Требуемая инициализация элемента очереди при обращении со значением второго параметра NULL не была реализована, что приводило к аварийному завершению работы процесса, попытавшегося использовать функцию именно для этого 5.

Не всегда несоответствие, обнаруженное при тестировании, является ошибкой в реализации. Например, расхождение между требованиями стандарта LSB и поведением функции basename(), обнаруженное при тестировании, являлось следствием ошибки в стандарте LSB 6.

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

Для обеспечения прослеживаемости требований в спецификациях используются цитаты из стандартов. Лицензия LSB позволяет цитировать текст стандарта без дополнительных ограничений, а для цитирования стандарта POSIX необходимо было получить разрешение от The Open Group, владеющего правами на текст стандарта. The Open Group дала положительную оценку деятельности ИСП РАН и предоставила все необходимые права на использование текста стандарта в каталоге требований и других компонентах тестового набора, создаваемых в ходе проекта.

Взаимодействие ИСП РАН с Free Standards Group происходило более тесно. Открытость стандарта LSB позволила специалистам ИСП РАН изучить в ходе работ по проекту инфраструктуру стандарта и внести предложения по ее улучшению. В результате Free Standards Group решила привлечь ИСП РАН к работам по развитию инфраструктуры стандарта LSB и улучшению сертификационного тестового набора.

На новом этапе сотрудничества ИСП РАН с Free Standards Group, намеченном на 2007 год, предполагается привлечение специалистов ИСП РАН к работам по следующим направлениям развития стандарта LSB:

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

Таким образом, сотрудничество с The Austin Group и Free Standards Group будет развиваться по трем направлениям - во-первых, это улучшение текста стандартов, уточнение формулировок и устранение противоречий, во-вторых, создание тестового набора, предназначенного для проверки дистрибутивов на соответствие стандарту LSB, и, наконец, развитие инфраструктуры стандарта LSB.

Опыт сотрудничества ИСП РАН с The Austin Group и Free Standards Group продемонстрировал интересную особенность открытых проектов.

Когда ИСП РАН начинал проект по разработке тестового набора, предназначенного для тестирования соответствия стандарту LSB, сообщество, образовавшееся вокруг этого проекта, практически не пересекалось с сообществами проектов The Austin Group и Free Standards Group. Только несколько человек из проекта OLVER участвовали в рабочем процессе этих сообществ.

В то же время цели проекта OLVER - обеспечение высокой надежности и совместимости платформы Linux с помощью использования открытых стандартов и наукоемких технологий верификации и тестирования - во многом совпадали с целями Free Standards Group и частично пересекались с целями The Austin Group. Это привело к появлению взаимного интереса сообществ OLVER и Free Standards Group и началу активного взаимодействия. Обратная связь, полученная проектом OLVER от сообщества Free Standards Group, позволяет определить приоритетные направления развития тестового набора, а поддержка Free Standards Group помогает распространять результаты проекта OLVER в сообществе Linux.

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

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




Страницы: предыдущая :: 1 :: 2 :: 3 :: следующая

Комментарии

аноним, Mon Dec 22 15:47:55 2008:
К сожалению, в статье ничего не сказано о стандартах ИСО - Информационные технологии.
Хотелось бы услышать о международном сотрудничестве и участии российских специалистов в этой сфере.
Eggog, Fri Jun 22 20:14:30 2007:
Ничего "бредового" не вижу.
Если не считать,конечно,сообщение предыдущего оратора:)
анонизм, Fri Jun 22 15:53:23 2007:
бред

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds