У linux проблемы с совместимостью

Глава 4. Проблемы совместимости

Содержание

4.1. На каких архитектурах/системах работает Debian GNU/Linux?

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

Текущий выпуск Debian GNU/Linux 10 содержит двоичный код для следующих архитектур:

amd64 : системы с 64-битными процессорами AMD с расширением AMD64 и любыми процессорами Intel с расширением EM64T, и 64-битным пользовательским окружением;

arm64 : поддерживает современные устройства на 64-битных процессорах ARM.

armel : машины ARM с процессором с обратным порядком байт;

armhf : альтернатива armel для машин ARMv7 с аппаратной плавающей запятой.

i386 : ПК с процессорами Intel и совместимыми с ними, включая Intel 386, 486, Pentium, Pentium Pro, Pentium II (Klamath и Celeron), Pentium III и почти все совместимые процессоры от AMD, Cyrix и другие;

ia64 : компьютеры Intel IA-64 («Itanium»);

mips :MIPS системы от SGI с прямым порядком байт — Indy и Indigo2; mipsel : MIPS системы с обратным порядком байт — Digital DECstation;

powerpc : некоторые машины IBM/Motorola PowerPC, включая модели PowerMac Apple Macintosh и машины с открытой архитектурой CHRP и PReP;

ppc64el : 64-битный перенос на PowerPC с порядком байтов от младшего к старшему, поддерживает некоторые новые процессоры PowerPC/POWER.

s390x : 64-битный перенос для машин IBM System z, заменил s390.

The development of binary distributions of Debian for hurd-i386 (for GNU Hurd kernel on i386 32-bit PCs), mipsel64 (for 64 bit MIPS in little-endian mode), powerpcspe (port for the «Signal Processing Engine» hardware), sparc64 (for 64 bit SPARC processors), sh (for Hitachi SuperH processors), and x32 (for amd64/x86_64 CPUs using 32-bit pointers) is currently underway.

Поддержка архитектуры m68k была прекращена в выпуске Etch (Debian 4.0), так как она не удовлетворяла требованиям ответственных за выпуск Debian. К данной архитектуре относятся машины Amiga и ATARI с процессорами Motorola 680×0, где x>=2 означает встроенный модуль MMU. Однако, даже не будучи частью официального стабильного выпуска, данный перенос всё ещё остаётся активным и доступен для установки, и может быть возвращён в число действующих в будущих выпусках.

Поддержка hppa (машины Hewlett-Packard с архитектурой PA-RISC ) и alpha (системы Compaq/Digital с архитектурой Alpha) была прекращена в выпуске Squeeze (Debian 6.0) по схожим причинам. Также в этом выпуске прекращена поддержка архитектуры arm , вследствие перехода на поддержку armel .

Support for the 32-bit s390 port (s390) was discontinued and replaced with s390x in Jessie (Debian 8). In addition, the ports to IA-64 and Sparc had to be removed from this release due to insufficient developer support.

Информация о загрузке, разметке диска, включении устройств PCMCIA (PC Card) и о прочих вопросах такого рода приведена в руководстве по установке.

4.2. На каких ядрах работает Debian GNU/Linux?

Beside Linux, Debian provides a complete, binary distribution for the following operating system kernels:

FreeBSD: provided through the kfreebsd-amd64 and kfreebsd-i386 ports, for 64-bit PCs and 32-bit PCs respectively. These ports were first released in Debian 6.0 Squeeze as a technology preview . However they were not part of the Debian 8 Jessie release.

Кроме этого, ведётся работа над следующими переносами:

avr32 — перенос для 32-битной архитектуры Atmel,

hurd-i386 — перенос для 32-битных ПК. В данном переносе будет использована GNU Hurd — новая операционная система, собираемая группой GNU,

sh — перенос для процессоров Hitachi SuperH.

Были попытки переноса дистрибутива на ядро NetBSD, где предоставлялись ядра netbsd-i386 (для 32-битных ПК) и netbsd-alpha (для машин Alpha), но эти переносы никогда не выпускались, и в данный момент работа над ними свёрнута.

4.3. Насколько Debian совместим с другими дистрибутивами Linux?

Debian developers communicate with other Linux distribution creators in an effort to maintain binary compatibility across Linux distributions. [1] Most commercial Linux products run as well under Debian as they do on the system upon which they were built.

Debian GNU/Linux придерживается Стандарта иерархии файловой системы Linux. Тем не менее, некоторые правила этого стандарта можно интепретировать по-разному, поэтому между Debian и другими системами Linux возможны различия.

4.4. Насколько исходный код Debian совместим с другими системами Unix?

Исходный код большинства приложений Linux совместим с другими системами Unix. Поддерживается почти всё, что есть в системах Unix System V, а также в свободных и коммерческих системах, происходящих от BSD. Однако, для бизнеса такое утверждение о Unix почти не имеет значения, потому что доказать это никак нельзя. В области разработки программного обеспечения необходима полная совместимость, а не совместимость «в большинстве случаев». Поэтому несколько лет тому назад назрела необходимость в стандартах, и теперь POSIX.1 (IEEE Стандарт 1003.1-1990) является одним из основных стандартов по совместимости исходного кода для Unix-подобных операционных систем.

ОС Linux ориентирована на соответствие POSIX.1, но стандарты POSIX стоят настоящих денег, а сертификация POSIX.1 (и FIPS 151-2) довольно дорога; это ещё более усложняет разработчикам Linux работу по достижению полного соответствия POSIX. Ввиду высокой стоимости сертификации маловероятно, что Debian получит официальное подтверждение о соответствии, даже если он полностью пройдёт аттестационный пакет. (Аттестационный пакет теперь свободно доступен, так что ожидается, что ещё больше людей будет работать над вопросами соответствия POSIX.1).

В Unifix GmbH (Брауншвейг, Германия) была разработана Linux-система, которая была сертифицирована как удовлетворяющая FIPS 151-2 (расширенный набор POSIX.1). Эта технология была доступна в собственном дистрибутиве Unifix, названном Unifix Linux 2.0, и в Lasermoon Linux-FT.

4.5. Можно ли использовать пакеты Debian (файлы «.deb») в системе RedHat/Slackware/… Linux? Можно ли использовать пакеты RedHat (файлы «.rpm») в системе Debian GNU/Linux?

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

Существует программа для распаковки пакета Debian на Linux-машине, работающей под «чужим» дистрибутивом, и она, в общем, работает, в том смысле, что файлы будут распакованы. Обратный вариант скорее всего тоже будет работать, т. е. программа сможет распаковать пакет для RedHat или Slackware на машине, работающей под Debian GNU/Linux, и разместить большинство файлов по нужным каталогам. Это в значительной степени стало возможным благодаря существованию (и строгому соблюдению) стандарта иерархии файловой системы Linux. Для преобразования различных форматов пакетов друг в друга используется пакет Alien.

То, что вы, скорее всего, делать не захотите

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

Лучший способ:

Стандарт Файловой Системы Linux (а, следовательно, и Debian GNU/Linux) требует, чтобы подкаталоги в /usr/local/ полностью находились в распоряжении пользователей. Поэтому пользователи могут распаковывать «чужие» пакеты в этот каталог, а затем лично управлять их настройкой, обновлением и удалением.

4.6. Как установить не-Debian программу?

Файлы в каталоге /usr/local/ не контролируются системой управления пакетами Debian. Поэтому хорошим вариантом будет размещение исходного кода нужных вам программ в каталоге /usr/local/src/. Например, файлы из пакета «foo.tar» можно распаковать в каталог /usr/local/src/foo . После сборки поместите двоичные файлы в /usr/local/bin/ , библиотеки в /usr/local/lib/ , а файлы настроек в /usr/local/etc/ .

Если ваша программа и/или файлы на самом деле должны находиться в каком-то другом каталоге, их всё равно можно сохранить в /usr/local/ , а в нужных местах создать соответствующие символьные ссылки на файлы из /usr/local/ . Можно, например, сделать так:

В любом случае, если вы получили пакет, авторские права на который позволяют его дальнейшее распространение, вам стоило бы подумать о создании из него пакета для Debian и отправке его в систему Debian. О том, как стать разработчиком пакета, читайте в руководстве по политике Debian (см. Раздел 12.1, «Какая ещё документация существует по системе Debian?»).

[1] The Linux Standard Base is a specification for allowing the same binary package to be used on multiple distributions. After Jessie (Debian 8) was released, Debian abandoned the pursuit of LSB compatibility. See this July 3, 2015 message from Didier Raboud and the following discussion for background information.

Источник

Совместимость Linux: есть ли проблема?

Алексей Федорчук
Открытые системы, 24 апреля 2007 г

Тема этой заметки навеяна статьей Алексея Гриневича, Дениса Марковцева и Владимира Рубанова «Проблемы совместимости Linux-систем«. И ее можно рассматривать как нечто среднее между рецензией на последнюю и дискуссией по некоторым ее положениям.

Расщепление Linux на множество дистрибутивов, несомненно, имеет место. Но посмотрим, «так ли страшен черт», для начала ответив на вопрос, что такое Linux. Прежде всего, это, конечно, ядро. И ядро это разрабатывается в рамках единого проекта, постепенно аккумулируя в себе ветки и заплаты множества разработчиков, и никакой тенденции к фрагментации системы на уровне ядра пока не прослеживается. Далее — комплекс системного окружения: средства загрузки и инициализации системы; утилиты поддержки функциональности ядра; средства поддержки взаимодействия пользователя с системой; общесистемные библиотеки; средства поддержки графического интерфейса; средства управления пакетами.

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

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

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

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

C точки зрения «базовых производителей», существует лишь три полностью оригинальные исторически системы: Slackware, Debian и Red Hat. Все остальные либо генетически с ними связаны, либо развивались под влиянием одной из них (правда, нельзя скидывать со счета и влияние систем BSD). С другой стороны, отход «клонов» от прародительского дистрибутива — лишь вопрос времени и интенсивности развития. Кому сейчас придет в голову, что Suse происходит от Slackware, а Mandriva (изначально Mandrake) исторически представляла собой просто Red Hat с KDE в качестве десктопа? Со стороны же третьей, вследствие открытой модели разработки все дистрибутивы находятся в состоянии постоянного взаимовлияния, и определить степень родства потомка с его прародителями часто не представляется возможным, что и имеет непосредственное отношение к проблеме совместимости.

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

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

Резкой грани между портируемыми и пакетными дистрибутивами нет. Первые в любом случае содержат прекомпилированную базовую систему, без которой было бы невозможно функционирование системы портов. Кроме того, никто не запрещает и распространять их в виде бинарных пакетов, сгенерированных системой портов (именно таков основной способ распространения FreeBSD). Пакетные же дистрибутивы часто содержат либо самостоятельные «портообразные» системы (Archlinux, CRUX), либо их средства пакетного менеджмента позволяют выполнить тотальную пересборку дистрибутива из исходников (Debian и его клоны). Тем не менее пакетные дистрибутивы могут распространяться без компилятора и сопутствующего инструментария, однако в них неотъемлемым компонентом оказывается какая-либо система управления пакетами. Какая именно — во многом зависит от формата пакетов: tar-архивы, компрессированные с помощью gzip или bzip2; rpm-пакеты и deb-пакеты. В соответствии с этим пакетные дистрибутивы могут быть разделены на три группы, каждая из которых обладает собственным набором низкоуровневых утилит для их установки, поэтому использование пакетов одного формата в дистрибутиве, рассчитанном на другой, обычно вызывает проблемы. Тем не менее здесь нет непреодолимой границы, поскольку существуют средства конвертации пакетов одного формата в другой, и кроме того, многие высокоуровневые системы управления пакетами, изначально предназначенные для пакетов deb-формата, успешно адаптируются и к другим форматам.

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

Давно прошли те времена, когда программы писались с ориентацией на какой-то конкретный дистрибутив. Сегодня они практически всегда создаются в расчете на использование в абстрактном Linux, а то и в Unix-подобной системе вообще. В любом случае, адаптация приложений под конкретный дистрибутив и под систему — это забота его сборщиков. Конечно, ожидать от сборщиков свободно распространяемых дистрибутивов (как и от разработчиков любого свободного программного обеспечения) гарантий совместимости было бы опрометчиво, хотя на практике такой гарантией выступает репутация. А вот распространители корпоративных редакций коммерческих дистрибутивов Red Hat, Novell, Mandriva такие гарантии предоставляют.

Тем не менее проблема совместимости дистрибутивов и прикладных программ существует, но касается она не открытого и свободного программного обеспечения, а проприетарного, не доступного в исходных текстах и потому не могущего быть адаптированным под конкретную систему путем их модификации. Сами же производители таких программ тестируют свои продукты на совместимость лишь с некоторыми дистрибутивами и не гарантируют их работоспособности в любых других системах. Так, для работы с СУБД Oracle до недавнего времени были сертифицированы только Red Hat и Suse (ныне к ним прибавился и «собственный» дистрибутив Oracle). Основные продукты IBM, такие, как DB2, ориентированы на Red Hat. Однако и здесь все не так страшно. Во-первых, отсутствие гарантии производителя вовсе не эквивалентно гарантированной неработоспособности ее продукции в других дистрибутивах. Во-вторых, например, целью создания таких клонов Red Hat, как Scientific Linux, как раз и является достижение полной функциональности родительской системы, в том числе и с точки зрения совместимости со сторонними приложениями. И в-третьих, запуск проприетарных программ в системах, для этого вроде бы не предназначенных, часто достижим с помощью специальных приемов.

Источник