(С) Костромин В.А.
март 2005 г.
Линуксцентр
2005-05-24
Все увеличивающее число дистрибутивов Linux невольно заставляет задуматься о том, а приведет ли это к тому, что системы станут несовместимыми. Как было рассказано в начале настоящей заметки, Unix-войны стали в свое время серьезным препятствием на пути развития Unix-систем. Не угрожает ли аналогичная опасность и Linux? Ведь у этой системы нет единого организующего центра или разрабатывающей систему компании. Конечно, разработкой ядра руководит Линукс Торвальдс, но ведь независимые разработчики не обязаны ему подчиняться, любой желающий может не только сформировать свой дистрибутив, но и создать свою версию ядра. Сообщество разработчиков Linux достаточно хорошо понимает эту опасность и предпринимает определенные усилия для выработки определенных стандартов, которые позволили бы ее избежать.
Некоей гарантией того, что подобная опасность не грозит Linux, является применение лицензии GPL и публикация исходных кодов. Развитие Unix в период Unix-войн сильно замедлилось в силу того, что конкурирующие производители тратили годы на внедрение аналогичных функций - просто потому, что у них не было доступа к базе решений, найденных другими. Независимая разработка одних и тех же функций не только стоила Unix годы, но и привела к судебным тяжбам. В Linux-сообществе ситуация принципиально иная. Исходные коды всего программного обеспечения доступны всем и отбор наиболее правильных и красивых решений происходит естественным образом. Тем не менее, очевидно, что разработка общепринятых стандартов очень полезна всему сообществу, так как позволяет упорядочить процесс разработки, договориться об общепринятых основах, не тратить силы на "тупиковые ветки".
Вообще говоря, Линус Торвальдс с самого начала придерживался в своей разработке основных стандартов, существовавших для Unix, в частности стандарта POSIX. Практически вся сетевая подсистема Linux - реализация открытых интернет-стандартов, изложенных в известных документах серии RFC. Графическая подсистема основана на стандарте X Window, который, по мнению многих экспертов, давно уже устарел, и его эффективность сомнительна - но все же это стандарт, и (кроме как для карманных компьютеров и других специфических задач) мало кто позволяет себе отойти от него.
Вероятно, одним из первых проектов стандартизации в Linux стала попытка упорядочить структуру каталогов файловой системы. Работа над этим проектом была начата в августе 1993 года. Вначале стандарт назывался проектом стандартов файловой системы - Filesystem Standarts project (FSSTND), и был ориентирован только на систему Linux. Его первая версия была выпущена 14 февраля 1994 года. Последующие редакции были выпущены 9 октября 1994 и 28 марта 1995 года. В разработке стандарта принимало участие большое количество добровольцев, но главным организатором был Дэниел Квинлан (Daniel Quinlan).
В начале 1995 года с участием сообщества разработчиков системы BSD была поставлена цель создания более общей версии FSSTND, предназначенной не только для Linux, но и для других UNIX-подобных операционных систем. В результате объединенных усилий разработка стандарта сосредоточилась на вопросах, которые являются общими для всех UNIX-подобных систем, включая операционные системы типа 4.4BSD. Учитывая расширение сферы действия стандарта, он был переименован в Filesystem Hierarchy Standard или, для краткости, FHS. Естественно, что «настоящие» UNIX-системы, созданные задолго до появления этого стандарта, ему не соответствуют. Однако FHS учитывает все положительные качества, присущие BSD и другим системам в части поддержки различных архитектур и учета требований работы в гетерогенных сетях. На момент написания этой статьи последней версией стандарта FHS является версия 2.3, которая была выпущена в августе 2004 года. Полный исходный текст этого стандарта можно найти в Интернет на сайте http://www.pathname.com/fhs/ (русский перевод версии 2.2.находится по адресу http://rus-linux.net/MyLDP/file-sys/fhs-2.2-rus/index.html).
В мае 1998 года Линус Торвальдс, Брюс Перенс (Bruce Perens) и несколько других известных сторонников систем с открытыми исходными кодами подписали декларацию о начале разработки проекта Linux Standart Base (LSB), который должен был определить набор тех компонент, которые должны присутствовать в любой "Linux-системе". Инициаторы проекта ставили амбициозную цель обеспечить в результате бинарную совместимость дистрибутивов, удовлетворяющих стандарту LSB. Под бинарной совместимостью понималось следующее:
Для того, чтобы обеспечить достижение поставленной цели, требовалось стандартизовать многие компоненты операционной системы.
Различные дистрибутивы Linux используют разные системные библиотеки, точнее
разные их версии. Поэтому программа, легко инсталлируемая в системе A, может
не установиться в системе B, использующей более раннюю версию библиотек, поскольку
существует проблема "обратной совместимости". Решение этой проблемы состоит в том,
что некая версия библиотеки объявляется стандартной и ей дается соответствующее имя,
например, ld-lsb.so.1
Если эта библиотека будет затем включена во все дистрибутивы, претендующие на соответствие
LSB, все приложения, которым эта библиотека необходима, будут работать без проблем. Это не
означает, что все другие версии этой библиотеки запрещены: они тоже могут быть включены
в дистрибутив, чтобы запускалось ПО, специфичное для данного дистрибутива.
Необходимо определить четкий перечень стандартных системных команд, включающий также указание на точное размещение соответствующих исполняемых файлов в файловой системе. Это необходимо для того, чтобы программисты знали, какие команды они могут вызывать из своих программ и скриптов, без риска получить сообщение об ошибке. Поэтому LSB определяет минимальный набор системных команд (man, cat, grep и т.д.), которые должны присутствовать во всех LSB-совместимых системах.
Стандартизация библиотек и системных команд не будет иметь большого смысла, если не известно, где эти библиотеки найти. Поэтому LSB включает в свой состав Filesystem Hierarchy Standard (FHS), благодаря чему авторы других программ и скриптов знают, где размещены соответствующие файлы.
Поставщикам программного обеспечения нужно многое знать о системе еще до того, как она полностью загрузилась. Поставщики больших баз данных, например, должны знать, на каком этапе загрузки становятся доступны основные базовые сервисы (например, сетевые службы). Поэтому LSB определяет также то, как должны быть структурированы инициализационные файлы, в какой последовательности они вызываются и где они хранятся в системе.
Для того, чтобы программисты, пишущие приложения для Linux, знали какие функции им доступны, LSB использует стандарт POSIX (Portable Operating System Interface), являющийся одним из самых важных стандартов для UNIX и UNIX-подобных систем.
Linux с самого своего возникновения был системой, предназначенной для работы в сети. Поэтому LSB также определяет механизмы, с помощью которых система взаимодействует с Интернет и сетями. Впрочем, в этом вопросе LSB в основном следует существующим стандартам.
Многие, хотя и не все приложения нуждаются в графическом интерфейсе. Размер графических приложений существенно увеличивается, если все необходимые библиотеки скомпилированы статически. LSB стандартизует протоколы нижнего уровня для того, чтобы управлять этим феноменом. На более высоких уровнях программисты могут делать все, что они хотят.
Использование унифицированого формата пакетов ПО - еще один предмет рассмотрения для LSB. Принятый LSB формат пакетов в основном соответствует широко распространенному формату RPM (определеному в Maximum RPM). LSB не определяет, как создавать пакеты. Однако, он содержит четкие указания о порядке именования пакетов и спецификации описаний взаимозависимостей пакетов.
Формат исполняемых файлов ELF ("executable linkage format") является стандартным в Linux. Он описывает структуру бинарных файлов с программами и библиотеками.
С целью поддержки процесса разработки стандартов для Linux была образована независимая некоммерческая организация Free Standards Group. В число ее основателей и участников входят такие известные фирмы и организации как Conectiva, Debian, Dell, Hewlett Packard, Hitachi, IBM, Miracle Linux, The Open Group, Oracle, Red Hat, Sun, SuSE and TurboLinux, а также отдельные независимые представители сообщества разработчиков открытого программного обеспечения.
В рамках Free Standards Group были образованы несколько рабочих групп, задачей которых является разработка отдельных стандартов. Разработка проекта Linux Standard Base стала задачей одной из таких рабочих групп. Другие рабочие группы занимаются разработкой следующих стандартов:
В октябре 2004 года организация Free Standards Group выпустила версию 2.0 стандарта Linux Standard Base (LSB). О своей поддержке нового стандарта заявили такие компании, как AMD, IBM, Dell, Hewlett Packard, Red Hat, Red Flag (основной китайский поставщик Linux) и т.д. Со временем все большее число компаний осознают, что следование стандарту LSB снижает расходы на тестирование производимых ими продуктов и предоставляет определенные преимущества в конкурентной борьбе, поскольку дает покупателям уверенность в высоких качествах продукта и отсутствии проблем с его эксплуатацией. Поэтому в 2005 году все новые компании заявляют о поддержке LSB. В их число входят, в часности, поставщик средств хранения данных Veritas, разработчик баз данных MySQL и поставщик программных средств управления Levanta.
Перечень программ и дистрибутивов, удовлетворяющих требованиям LSB, можно просмотреть здесь.
Кроме стандартов, разрабатываемых Free Standart Group, нужно упомянуть еще консорциум Embedded Linux, который разработал проект стандарта по использованию Linux во встраиваемых устройствах, таких как сетевые маршрутизаторы и заводские роботы.