Проблемы совместимости Linux-систем

Если вернуться в конец 90-х и окунуться в мир операционных систем того времени, то вряд ли у кого возникнет сомнение в безраздельном царствовании Unix-совместимых систем.

Алексей Гриневич, Владимир Рубанов, Денис Марковцев

Если вернуться в конец 90-х и окунуться в мир операционных систем того времени, то вряд ли у кого возникнет сомнение в безраздельном царствовании Unix-совместимых систем. На стороне Unix все — семейство этих операционных систем изучают в университетах, для него созданы сотни тысяч приложений, оно успешно применяется в различных отраслях экономики, о нем написано море книг и документации. Правда, нельзя приобрести именно Unix, а можно купить IBM AIX, BSD, HP-UX, Sun Solaris и т.д. При этом требуются дополнительные усилия для того, чтобы программа, созданная, скажем, для AIX, заработала под Solaris. Различные клоны Unix оказались слабо совместимы. Аналогичные проблемы имеются сегодня и для ОС Linux.

Для решения инфраструктурной проблемы слабой совместимости различных версий Unix в 1985 году в рамках IEEE была начата работа над стандартом, обеспечивающим переносимость программного обеспечения. В 1990 году увидел свет стандарт IEEE 1003, также получивший название POSIX [1], который регламентировал программные интерфейсы (API) и перечень команд Unix-клонов. Однако для игроков рынка Unix унификация породила сложные политические проблемы: любое решение, любой выбор между альтернативными вариантами для достижения согласия ведет к тому, что «более стандартным» признается решение одного производителя по сравнению с решением другого. В результате стандарт изобилует многозначными утверждениями типа «в данном случае возможен один из двух альтернативных вариантов поведения» и белыми пятнами наподобие «стандарт не регламентирует поведение функции в этом случае». В конце концов, фрагментация стала одной из основных причин поражения мира Unix. Игроки этого рынка конкурировали не только с другими типами операционных систем, но и друг с другом, вводя частные расширения и закрытые интерфейсы, ограничивая круг возможных приложений каким-либо одним клоном.

Появившаяся в начале 90-х годов ОС Linux, вобравшая в себя код, созданный в рамках движения GNU, и впитавшая основные идеи Unix, благодаря открытости и независимости стала универсальным компромиссом. Ее код реализовывался с нуля, не опираясь на какую-либо реализацию, а только на текст стандарта POSIX. В результате система получилась изначально POSIX-совместимой, а независимость позволила объединить усилия различных игроков рынка Unix в борьбе за «возврат» упущенного сегмента операционных систем для ПК. Однако проблема фрагментации осталась актуальной и для Linux: наличие конкурирующих между собой дистрибутивов вызывает опасения в вероятном повторении судьбы Unix.

На первый взгляд, сама опасность фрагментации выглядит довольно призрачной — фактически имеется общий код, большинство дистрибутивов работают на основе одного и того же ядра, одних и тех же библиотек, что во многом определяет совместимость. Казалось бы, и приложения должны сохранять работоспособность и совместимость между различными версиями Linux. Но это не получает подтверждения на практике. Наряду с фрагментацией рынка дистрибутивов Linux по подходам и дополнительной функциональности, наблюдаются существенные перекосы в поддержке различными клонами даже распространенных и стандартных приложений — в различных дистрибутивах используются разные версии ядра и системных библиотек (в первую очередь, glibc). Это ведет к тому, что состав и поведение системных интерфейсов, предоставляемых системой приложениям, меняются от дистрибутива к дистрибутиву. Для того чтобы не повторить печальный опыт клонов Unix, в 1998 году в рамках специально созданной организации Free Standards Group (сейчас Linux Foundation [2]) началась работа над стандартом LSB (Linux Standard Base — «базовое семейство стандартов Linux»). Благодаря усилиям со стороны организаций X/Open, IEEE и ISO, открывших стандарт POSIX и часть тестов для свободного доступа, был заложен фундамент в дело стандартизации Linux.

Но что именно и зачем нужно стандартизовать? Неужели единый открытый код сам по себе не является единым и открытым стандартом?

Проблемы совместимости приложений

Как проявляются различия между дистрибутивами Linux на практике и насколько серьезна проблема? Приведем пример. Основу коммерческих предложений корпорации IBM составляют пять линеек программных продуктов: DB2, Websphere, Rational, Tivoli и Lotus. Практика показывает, что поддержка всех пяти линеек для одного дистрибутива Linux обходится ежегодно в миллионы долларов, которые идут на разработчиков и тестировщиков, ответственных за поддержку приложений под конкретный дистрибутив Linux. Следовательно, поддерживаются те дистрибутивы, для которых прибыль от продажи продуктов превышает эти миллионы; фактически это только дистрибутивы SuSE и Red Hat. Так возникает ситуация несоответствия — то, что работает на одних дистрибутивах, не запускается на других.

Совсем другая ситуация наблюдается для Sun Solaris. Прежде всего, в Sun Microsystems гарантируют, что программа, скомпилированная для Solaris 2.6, будет работать без перекомпиляции и под версией 10. Разработчики Sun прилагают огромные усилия для этого; при каждом изменении кода прогоняется набор более чем из 2400 приложений различного назначения и состава. Более того, если кто-то обнаруживает, что приложение перестало работать по причине несовместимости между версиями Solaris, то в Sun берут на себя ответственность и расходы на исправление этого несоответствия. В случае с ОС Linux данная работа долгое время не велась, приложения и дистрибутивы жили своей собственной обособленной жизнью. Самым печальным при этом является отсутствие универсального способа написания программы таким образом, чтобы гарантированно обеспечить переносимость. На решение этой проблемы и направлены усилия консорциума Linux Foundation, представляющего интересы основных игроков Linux-рынка.

Структура Linux

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

Бытует мнение, что если программа перестала работать при смене дистрибутива Linux (или его версии), то, имея исходные коды, ее очень легко подправить, а потому и проблемы с совместимостью нет. Прежде чем обсуждать, так это или нет, рассмотрим сначала структуру ОС Linux.

«Обобщенная» модель системы на базе Linux представлена на рис. 1.

Каждая конкретная Linux-система создается для работы одного или нескольких приложений, однако кода самого приложения недостаточно, чтобы извлечь необходимый пользователям сервис из аппаратуры — большинство приложений использует в своей работе обращения к функциям библиотек. Стандарт LSB Core 3.1 определяет следующие системные библиотеки: libc, libcrypt, libdl, libm, libpthread, librt, libutil, libpam, libz, libncurses. В современных Linux-системах интерфейсы этих системных библиотек реализуются библиотеками glibc, Linux-PAM, zlib и ncurses, которые на самом деле реализуют больше интерфейсов, чем определено в LSB Core.

26.02.2007г