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

В настоящее время в мире Linux выделяются три центра инноваций — Red Hat, Novel/SuSE и Debian, в составе которых имеются крупные команды разработчиков для доведения развивающихся в инициативном порядке программных систем до состояния целостных коммерческого продукта. Компания Red Hat получила известность благодаря своей программе пакетирования RPM, имя Novell связывают с утилитой установки и конфигурирования YaST, которая долгое время сохраняла статус закрытого продукта, а Debian — с системой многоплатформенной разработки и распространения программ. Эти команды внесли существенный вклад в развитие важных для коммерческих Linux-продуктов технологических компонентов: многоплатформенной разработки, пакетирования и установки программ, а также комплексной настройки всей системы.

Проблема несовместимости дистрибутивов

Достаточно вспомнить о сложностях развертывания проекта Linux Standard Base (LSB), начавшегося в 2002 году при поддержке общественной организации Free Standards Group. Первая версия LSB содержала только рекомендации, определяющие, в каких каталогах должны находиться компоненты операционной системы — библиотеки, исходные тексты, документация и т.п. Впоследствии выяснилось, что этого недостаточно для обеспечения совместимости, и появились следующие версии. Сейчас принята спецификация LSB 2.1, которая послужила основой для документа, направленного на утверждение в ISO (правда, в дистрибутивах Linux пока реализована только версия 2.0).

Как известно, ядро Linux контролируется Линусом Торвальдсом; все ключевые изменения ядра согласуются с ним или с другими координаторами. Состав и базовая функциональность ядра всегда одинаковы в одной версии, но дабы у производителей не возникало проблем с переносом их продуктов с одной версии ядра на другую, для системных вызовов ядра необходим стандарт. Минимальным требованием является соблюдение спецификации ISO POSIX, на которую изначально опирались разработчики Linux. В LSB вошла расширенная спецификация POSIX, принятая ISO в 2003 году, но в ней не определено устройство ядра — описаны лишь интерфейсы, с помощью которых приложения с ним взаимодействуют. Впрочем, в состав ядра входят не только базовые алгоритмы управления памятью, распределения процессорного времени и организации взаимодействия процессов ОС, но и драйверы периферийных устройств, за которые обычно отвечают сами производители. А помимо общих для всех платформ алгоритмов в ядре имеются аппаратно зависимые части, которые также развиваются отдельно.

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

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

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

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

Несовместимость может возникать при запуске приложений заранее определенными пользователями и их группами (mail, shutdown, lp и др.). А потому стандарт должен закреплять еще и размещение ресурсов приложений: конфигурационные файлы, сценарии инициализации, графические файлы и документация, а также наименование стандартных пользователей и групп (в смысле ОС), от имени которых может потребоваться выполнить установку приложения.

Linux Standard Base

Базовый набор спецификаций LSB называется LSB Base и включает в себя LSB-Core, LSB-C++ и LSB-Graphics, отвечающие за стандартизацию соответствующих элементов операционной системы. LSB-Core описывает стандартное расположение файлов, LSB-C++ — интерфейс ядра на языке С++, а LSB-Graphic — работу приложений с X Window. Предполагается, что разработчики будут задействовать ту или иную спецификацию, если их приложение использует соответствующую функциональность, и не прибегать к помощи функций, не описанных в спецификации. Только в этом случае гарантируется корректная работа приложений во всех LSB-совместимых дистрибутивах.

В спецификациях есть части, зависящие от платформы (скажем, LSB-IA-32 — спецификация LSB для 32-разрядных процессоров Intel-архитектуры). Эти документы определяют особенности процессорной архитектуры, которые могут повлиять на совместимость приложений. Фактически, спецификация стандарта для конкретной архитектуры является комбинацией общего документа LSB-generic и архитектурно зависимой части LSB-arch; обе обязательны к исполнению.

Базовым для Unix стандартом является формат представления исполнимых программ и библиотек в виде файлов. Этот стандарт входит в состав спецификации System V ABI и называется Executable and Linking Format (ELF). Он важен и для Linux: переход версии ядра с 1.x на 2.x связан с поддержкой формата ELF и отказом от устаревшего a.out. После появления второй версии ядра ELF является существенной частью Linux, а его спецификация перекочевала в LSB.

Еще одним институтом стандартизации, на документы которого опирались создатели LSB, является IETF. Так, в LSB используются стандартный алгоритм хеш-функции MD5 (RFC 1321), протокол удаленного вызова процедур RPC (RFC 1833), стандарты сжатия информации ZLIB (RFC 1950), DEFLATE (RFC 1951), GZIP (RFC 1952), а также стандарт на электронную подпись OpenPGP (RFC 2440). Есть и еще несколько спецификаций, на которые опирались разработчики LSB, в частности спецификации пакетирования приложений и проверки целостности пакета, устанавливаемого в операционной среде.

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

В качестве стандарта пакетирования программ служит RPM, что затрудняет обеспечение соответствия LSB для дистрибутивов, не имеющих его поддержки, например Debian. Впрочем, в стандарте есть приписка, что при необходимости разработчики дистрибутивов могут использовать и другие программы пакетирования. Неизменным остается лишь требование того, чтобы после установки на клиентскую машину все компоненты приложений располагались и именовались в соответствии с LSB. Таким образом, часть Linux Packaging Specification фактически является необязательной: она лишь определяет стандартный формат представления программ в файлах RPM.

Спецификация LSB-C++ устанавливает интерфейс с ядром Linux для программ на языке программирования С++. Этот интерфейс собран в библиотеку libstdcxx и определяется стандартом на С++, который специфицирован документом ISO/IEC 14882: 2003, а также спецификацией бинарного интерфейса Itanium C++ ABI (Revision: 1.75). А спецификация LSB-Graphics содержит описание интерфейса для графических библиотек, которые связаны со стандартами на X Window и OpenGL.

Поддержка LSB

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

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

Библиотеки LSB

Стандарт LSB предполагает наличие на клиентской машине ряда общих библиотек:

  • libdl — функции динамического связывания приложений;
  • libcrypt — набор функций шифрования;
  • libz — пакет утилит архивирования;
  • libncurses — утилиты управления курсором и псевдографикой в терминальном режиме;
  • libutil — различные утилиты;
  • libpthread — библиотека потоков, которые отвечают спецификации POSIX;
  • libpam — функции аутентификации пользователей;
  • libgcc_s — набор определений библиотеки Unwind.

Стандарт также предусматривает наличие библиотек libm и libc, определения которых зависят от используемой процессорной архитектуры. Функции этих библиотек таковы:

  • libc — интерфейсы RPC, IPC, системных вызовов, стандартного ввода/вывода, сигналов, локализации, сетевых сокетов, работы со строками и регулярными выражениями, манипуляций со временем и другие интерфейсы, связанные с платформой;
  • libm — математические функции.

Наконец, стандартом предусмотрены следующие графические библиотеки:

  • libX11 — функции работы с системой X Window;
  • libXt — набор утилит для работы с X Window (X toolkit);
  • libGL — набор функций для работы с OpenGL;
  • libXext — функции, расширяющие базовую функциональность X Window;
  • libICE — функции, обеспечивающие взаимодействие разных клиентов одного X-сервера (Inter-Client Exchange);
  • libSM — утилиты управления сеансами протокола X Window.

Сильные стороны и ограничения LSB

В число разработчиков LSB входят ведущие игроки ИТ-рынка, такие как IBM, HP, Intel, Sun Microsystems, AMD, а также производители наиболее популярных дистрибутивов Mandriva, RedHat и некоммерческая организация Software for Public Interest, представляющая интересы Debian. Участвовать в разработке LSB может любой желающий, подписавшийся на соответствующие списки рассылки, поэтому принятие решений вряд ли сможет монополизировать какая-либо группа компаний.

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

Кроме того, LSB определяет порядок работы стандартных утилит, входящих в любой дистрибутив Linux. Это делает LSB похожим на Single Unix Specification Version 3, на котором основаны ядро Linux и приложения: они часто используют shell-сценарии для установки, удаления, инициализации или прекращения работы программного обеспечения. В таких сценариях чаще всего применяются стандартные утилиты, а LSB описывает, какие параметры они должны иметь. Кроме того, LSB включает в себя стандарт иерархии файловой системы (Filesystem Hierarchy Standard, FHS), регламентирующий размещение файлов и библиотек (www.pathname.com/fhs).

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

Формат бинарных файлов ELF (www.linuxbase.org/spec/refspecs/elf.pdf) является фактическим стандартом для всех дистрибутивов, основанных на GNU/Linux. LSB поддерживает его использование и включает в себя набор тестов для проверки на совместимость.

Стандарт LSB разбит на несколько частей в соответствии с платформами, на которых работает ядро Linux, а также с уровнями совместимости. Так, текущая версия LSB 2.9 опубликована для аппаратных платформ IA-32, IA-64, PowerPC32, PowerPC64, S390 и S390X и делится на части Core, Embedded, Desktop, Java, C++, Packaging и Graphics. Каждая из частей отвечает за соответствующую область применения LSB-совместимого программного продукта.

Примечательно, что значительная часть возможностей GNU/Linux не покрывается стандартами LSB. Производителям дистрибутивов Linux, интеграторам и разработчикам выгодно не только то, что LSB стандартизует основные приложения, но и то, что LSB не описывает требования к операционной системе «до последнего файла». LSB определяет некий уровень нарушения совместимости с приложениями, ниже которого «опускаться» недопустимо. Ядро Linux, которое находится выше этого уровня, может развиваться без ограничений.

Благодаря этому разработчик дистрибутива свободен в выборе методов и стратегий администрирования системы. Например, LSB не требует выполнения четкой политики безопасности в отношении создания и администрирования пользовательских и групповых учетных записей, а также прав на файлы. LSB-совместимые приложения будут работать и в том случае, если администратор поменяет настройки безопасности, установленные по умолчанию (конечно, в разумных пределах: неумелый администратор может сломать всю систему, и LSB не позволяет предотвратить такое развитие событий). Влияние LSB не распространяется и на средства настройки программного обеспечения; так, SuSE и Red Hat содержат принципиально разные программы настройки. Пользователь часто выбирает тот или иной дистрибутив Linux, ориентируясь именно на удобство настройки, а потому Red Hat и SuSE могут конкурировать в этой области, сохраняя совместимость с существующими приложениями.

В рамках проекта LSB созданы специальные средства, помогающие разрабатывать совместимые программные продукты. Это среда для сборки приложений и пакет Application Battery, который содержит стандартный набор библиотек и скомпилированных специальным образом программ. Application Battery используется для тестирования программ на совместимость с LSB, а также дает примеры того, как надо собирать LSB-совместимые приложения. Программа, претендующая на совместимость с LSB, может использовать только приложения из Application Battery. Сегодня в этот пакет входят Apache, celestia, expect, groff, lynx, python, rsync, samba, tcl, xpaint и xpdf.

Для разработчиков дистрибутивов имеется свой набор тестов и пример реализации LSB-совместимого дистрибутива; он не является полнофункциональным и разрабатывается параллельно с LSB в качестве «испытательной площадки» для новых стандартов. В конце концов, LSB разрабатывался как набор стандартов для широко распространенных дистрибутивов, а не для их адаптации (скажем, в целях обеспечения работы со встроенными устройствами). Правда, в некоторых случаях была бы полезна совместимость с LSB специальных решений, основанных на GNU/Linux, поскольку в LSB есть аспекты, которые неуместны для таких случаев.

В качестве среды общения и координации LSB использует стандартные средства, принятые в проектах Free Software, — списки рассылки, IRC и CVS. Каждый, кто заинтересован в развитии базы стандартов для Linux, может принять участие в проекте. Благодаря проведению открытых дискуссий после принятия очередной версии стандарта несогласных с тем или иным пунктом требований почти не остается. Кроме того, несмотря на немалый объем стандартов, коллективная разработка способствует тому, что они не содержат внутренних противоречий.

У LSB немало преимуществ, значимых для разработчиков программных продуктов для платформы Linux, таких как надежные рекомендации для создания хорошего кода. К сожалению, еще не все распространенные дистрибутивы сертифицированы на соответствие с LSB; из наиболее распространенных следует назвать SuSE 9, Red Hat Enterprise Linux 3 и Mandrake Corporate Server 3.0. Среди поставщиков специализированных решений соответствующий сертификат получил основанный на Debian продукт Progeny Componentized Linux Core. В случае всеобщего принятия LSB приложения смогут работать на базе любого дистрибутива Linux, а не разрабатываться для конкретных сочетаний аппаратной платформы и дистрибутива. Аккуратно определяя рамки совместимости приложений, LSB не угрожает основным идеям Open Source и дает каждому разработчику свободу внесения нововведений в приложения при сохранении их совместимости.

Петр Новодворский (Peter.Novodvorsky@ru.ibm.com) — технический специалист центра компетенции Linux компании IBM (Москва).

Имена LSB

Стандарт LSB определяет ролевые имена пользователей, которые могут применяться в операционной системе. Обязательных пользователей всего три: root (администратор всей системы) и два унаследованных пользователя — bin и deamon. Необязательные пользователи и группы таковы:

  • adm — альтернативный администратор;
  • lp — демон принтера;
  • sync — учетное имя для синхронизации системы;
  • shutdown — имя для выключения системы;
  • halt — имя для приостановки системы;
  • mail — имя демона электронной почты;
  • news — имя демона системы распространения новостей;
  • uucp — имя демона пересылки электронной почты по протоколу UUCP;
  • operator (группа root) — имя для обозначения привилегий оператора;
  • man — имя демона форматирования подсказки;
  • nobody — имя, используемое демоном NFS.

Все эти имена позволяют правильно настроить права доступа для различных подсистем Linux.