Совместимость 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, как раз и является достижение полной функциональности родительской системы, в том числе и с точки зрения совместимости со сторонними приложениями. И в-третьих, запуск проприетарных программ в системах, для этого вроде бы не предназначенных, часто достижим с помощью специальных приемов.
Источник
Совместимость различных версий Linux при запуске бинарных файлов
Добрый день! Не подскажете насчет совместимости различных версий Linux для следующей ситуации. Допустим, я пишу «Hello, world!» в старом RedHat, собираю g++ -o hello main.cpp. И потом запускаю ./hello на последней Ubuntu. Работать у меня не должно? В чем здесь проблема?
Как тогда поступают в таких ситуациях? Отправляют исходники и кто-то собирает бинарные файлы на той машине, на которой нужно будет запускать?
Столкнулась с этой проблемой. «Hello, world!», собранный на RedHat на Ubuntu выдает следующее: bash: ./hello: No such file or directory
Версия libc, не может найти соотв. версию ld.so.
Это как, подскажите,пожалуйста? Как собрать статически,допустим «Hello, world!»?
вначале нужно файл программы исполнимым сделать командой «sudo chmod +x hello» после копирования на целевой компьютер.
И перед тем как начинать программировать нужно почитать хотя бы книжки по использования linux-основанных систем.
То есть задача стоит так,что у меня есть RedHat и последняя Ubuntu. И я хочу, чтобы то, что я собрала, по возможности, запускалось на большинстве версиях Linux.
Смотри в справке опции g++ -static*. Там их много.
понятно, что все права на исполнение есть.
нехрен собирать при помощи g++, abi которого полощет, как говно в проруби
Работать у тебя не должно, когда ты собираешь хело верлд на новой убунте и запускаешь на старом редхете
Ето у тебя ld.so лежит не там где ожидается.
patchelf —set-interpreter `patchelf —print-interpreter /bin/sh` ./hello
Ух-ты, какая полезная тулза. Дякую
Командная строка компилятора будет примерно такой:
Тогда копия (не совсем, но по сути то же самое) glibc и всех остальных требуемых программой библиотек будет встроена в бинарник.
(К слову, glibc — это GNU’шная реализация libc, основной библиотеки Си.)
вам для курсовика или зачем это?
Одна из главных концепций unix или nix-подобных систем: мобильность т.е. возможность развернуть программу на любой платформе за счет ее компиляции на этой платформе, а не таскания везде бинарника — что нибудь, да и отвалится.
Из современных дистров, только gentoo поддерживает в основном данную концепцию.
Считается, что со временем и ростом вычислительных мощностей, компилирование будет занимать все меньше времени и затрат.
проприетарный блоб, например. дадут тебе исходник, ага, жди
проприетарный блоб, например. дадут тебе исходник, ага, жди
к сожалению реальность такова, хотя реверс никто не отменял и на nix-платформах это сделать наверное проще.
RE: Совместимость различных версий Linux при запуске бинарных файлов
Её никто не гарантирует и соответственно если она и есть то это <чудо/удача/счастливая случайность>и не более того. Где она точно будет так это в тех дистрибутивах, которые используют один и тот же toolchain т.е. в принципе в buntu т.е. там где отличия только в „косметике“.
А почему не должно? Сейчас как раз такую ситуацию попробовала. Собираю на ubuntu
Дай угадаю: шапка 32-битная, а бубунта 64-битная?
То есть нельзя ли как-то,чтобы можно было и на ubuntu собирать?
Источник
Расскажите все про Linux программисту C++
Какое-то время назад я работал с Red Hat Linux. И вот после большого перерыва мне требуется снова вернутся в пингвиний мир, но столько воды утекло! Может соберем все вместе здесь эдакий FAQ для программиста C++, но чайника в Линуксах?
1. В чем различие между основными популярными дистрибутивами Linux?
> Основная разница это система пакетов. (deb, rpm и т.д.) Также под какие архитектуры выпускается дистрибутив. (sl_bug)
> Основные отличия: Менеджер пакетов, набор ПО, настройки по умолчанию. (Evgeny_Shiryaev)
> (в дополнение к Evgeny_Shiryaev) еще иногда отличаются способом конфигурации сервисов, стартуемых при загрузке. Пример — /etc/conf.d/net в Gentoo и /etc/network/interfaces в Ubuntu. Также для каждого дистрибутива характерен свой способ задания списка стартуемых при загрузке сервисов. Иногда различаются способом организации самих конфигурационных файлов (один файл или кучка файлов и макрос, их собирающий). (xtreme)
> В пакетной системе, в инсталляторе, в системных скриптах. В версиях ПО и наборе ПО по умолчанию. (Arceny)
2. Почему следует предпочитать системы BSD перед системами Linux?
> Кто вам это сказал? Выбирать нужно по потребностям. (sl_bug)
> Лично я не вижу весомых преимуществ BSD-систем перед Linux-системами. (Evgeny_Shiryaev)
> Холиварный вопрос. Выбор системы зависит от поставленной задачи. Однако, в BSD более продуман сетевой стек и присутствуют такие полезные шняжки, как accf_http и accf_data. В Линукс я пока не видел замены кроме TCP_DEFER, которая работает несколько иначе. (xtreme)
3. Существуют ли полностью бесплатные дистрибутивы Linux?
> Да, причем их большинство. (Evgeny_Shiryaev)
> Я бы сказал, что бесплатно-доступных дистрибутивов — абсолютное большинство. (xtreme)
> Да, большенство. Debian или Ubuntu. Или Fedora. Или Gentoo. (Arceny)
4. Почему вообще дистрибутив Linux является платным, ведь он построен на базе open-source программного обеспечения и бесплатного ядра Linux?
> Обычно платной является поддержка а не дистрибутив (sl_bug)
> Плата идет не за сам дистрибутив, а за поддержку его (обновления, техсаппорт, и т.д.). (Evgeny_Shiryaev)
> Весьма существенный момент для разработчика:
В платном дистрибутиве SUSE SLES без подписки недоступны также и пакеты с исходными кодами (src.rpm = мэйнстрим исходники + дистрибутивные апдейты, патчи, спеки, конфиги).
Пересобрать пакет можно только из исходного (мэйнстрим) tar.gz (в лучшем случае — из src.rpm opensuse, с перерисовыванием зависимостей и прочими прелестями).
При этом, естественно, рушится вся система апдейтов.
И, возможно, совместимость с остальными пакетами системы,
в том числе с темже самым пакетом, поставленным из бинарников.
Скорее всего, аналогичная ситуация с RedHat и другими платными дистрибами. (qmax)
> (опять же в дополнение к Evgeny_Shiryaev) Тут надо помнить, что «открытые исходные тексты» и «бесплатно» — это все-таки разные понятия. Обычно OpenSource-лицензии не запрещают продавать продукты, выпущенные под ними или с их использованием. (xtreme)
> Техподдержка, коробка, полиграфия… Либо включенные проприентарные компоненты, удалив которые получим полностью лицензионно чистую версию. (Arceny)
> Вы имеете возможность платить за поддержку. Если хотите RHEL без поддержки — используйте CentOS. В остальном — есть Ubuntu (которая бесплатна, но появилась возможность поддержки), OpenSUSE, Fedora (здесь вообще только бесплатный вариант)). (kost_bebix)
5. Если мне требуется установить много машин с Linux есть ли лицензия, которая позволит мне один раз купить дистрибутив и ставить его на сколько угодно машин? Или опять-таки есть ли полностью бесплатный Linux?
> Можно даже не купить, а свободно скачать и поставить на любое количество машин. Но если Вы заинтересованы в поддержке, то тогда, действительно, лучше купить. (xtreme)
> По условиям лицензий Debian и Ubuntu — вы можете ставить их на неограниченное количество PC. Но в России вам придётся купить коробочную версию. По идее — достаточно одной коробки на одну компанию. (inkvizitor68sl)
> Да все они (из популярных): Fedora, Ubuntu, Linux Mint, OpenSUSE, Mandriva, CentOS, Debian, Slackware, Arch, Gentoo являются бесплатными. (kost_bebix)
6. Есть ли достойные дистрибутивы «от отечественного производителя»?
> ALT Linux возможно (sl_bug)
> На этот вопрос нельзя ответить объективно. Лично на мой взгляд нет. Однако если будете смотреть на «наши» дистрибутивы, смотрите на ALT Linux. (Evgeny_Shiryaev)
> есть. InfraLinux например. Но в большинстве случаев они платные. (именно достойный) (inkvizitor68sl)
7. Являются ли дистрибутивы Линукс совместимыми на уровне бинарных исполняемых файлов? Можно ли взять файл из Ubuntu и запустить его на Fedora, на FreeBSD?
> можно из Ubuntu 32bit на Fedora 32bit (sl_bug)
> Дистрибутивы Linux да. На FreeBSD можно запустить бинарники Linux, однако не напрямую. (Evgeny_Shiryaev)
> Обычно — да. Трудности возникают, когда бинарник использует некоторые подключаемые библиотеки, а исходная система (от которой бинарник) и целевая (где запускается бинарник) имеют разные версии данных библиотек, в которых разные функции могут, к примеру, называться по-разному, либо вообще отсутствовать. Но, статически собранные бинарники вполне себе переносимы. Примеры — Opera, Adobe-Flash-плагин для браузеров, Skype и т.д.
В FreeBSD же совместимость с линуксовыми бинарниками достигается за счет эмуляции для них линуксового окружения, для чего, как я помню, используются обычные линуксовые библиотеки от Fedora, плюс спец-модуль в ядре, позволяющий это дело. (xtreme)
> Линукс — да, если есть нужные shared-libraries. Бинарная совместимость Linux >> BSD существует. Но тупо взять пакет и запустить в большенстве случаев не получится, подробностей не знаю. (Arceny)
> большинство бинарников запустятся в любом дистрибутиве. Некоторые программы распространяются именно в таком виде (firefox с сайта например). Или basket. (inkvizitor68sl)
> Редко. Смотря какой файл. Есть утилита Alien, которая из .deb-пакетов делает .rpm, но это костыль. Если пишешь на C++ — почитай про «Opensuse Build Service» — это типа место, где ты свой проект будешь удобно собирать сразу под все системы какие необходимо. (kost_bebix)
8. Каким образом при написании C++ программ обеспечить максимальную совместимость между Линукс-дистрибутивами на уровне исходных кодов? Какие библиотеки следует использовать?
> Широко распространённые, например Qt. OpenSource. Включенные в основные репозитории. (Arceny)
> Практически любые, но я лично тепло отношусь к Qt, которая есть и в Виндоус и МакОС. А так — гугл всегда найдет что-то абстрактное от дистрибутива для каждой конкретной задачи. (kost_bebix)
> Ах да. И, собственно, о главном — об отличии написания под виндоус. Все просто — под виндоус ты писал программу, которая использовала некоторые библиотеки — ты эти библиотеки пихал прямо в сборку программы и собирал один большой кусок. В линуксе же принято иначе, — ты пишешь программу, а затем создаешь .deb/.rpm, где описываются библиотеки и их версии.
Профит:
— в линуксе если у меня уже установлена эта библиотека — не нужно ничего качать
— если в библиотеках находятся уязвимости — они обновляются и все, кто их использовал защищены
Проблемы:
— если дистрибутив решит использовать новую версию (ветку) библиотеки — все может сломаться. Поэтому надо пилить (если нужна максимальная кросс-дистрибутивность) (kost_bebix)
9. Допустим требуется какое-то нестандартное решение, например, какой-то специальный вызов ядра. Каким образом можно узнать, что данная система поддерживает этот вызов?
> Экспериментальным путём или спросив в списках рассылки, форумах, у разрабов, _почитав документацию_. (Arceny)
> Если есть ядро — значит есть и функция. Дальше надо смотреть на конкретику. (kost_bebix)
10. Есть ли хорошие альтернативы gcc для разработчика на C++? Всегда ли gcc входит в состав дистрибутива?
> 10. icc, всегда (sl_bug)
> Нет, не всегда. Свободных альтернатив не знаю. (Arceny)
11. Какие IDE и под какими оконными менеджерами (или как это называется?) вы используете для программирования на C++? Какой отладчик?
> IDE — Eclipse вроде бы популярен (со слов друга-программиста на C++ и Java, на истину в последней инстанции не претендует); отладчик — gdb. (xtreme)
> gdb — отладчик. к нему много разных обёрток.
Например для программирования с использованием GUI тулкита Qt использую QtCreator.
А вообще разных IDE много. Google. (Arceny)
> Если человек задаёт к вопросу об IDE отдельно вопрос про отладчик, он вряд ли получит что-либо кроме vim+gdb. Под IDE обычно подразумевают среду, в которой уже настроены трассировки с помощью горячих клавиш, просмотр отладочной информации и пр. В этом случае я бы порекомендовал Qt Creator, KDevelop, Code::Blocks, Eclipse или NetBeans. (Lockal)
> В Eclipse не очень удобно делать отладку, да и подтормаживает. NetBeans тормозит. KDevelop — фигня. Qt Creator более-менее (юзать можно).
Достойной Linux-альтернативы VS нет 🙁 Особенно что касается удобства отладки. (GooRoo)
> KDE4.3.1 + QtCreator — хорошее решение. Я использую Emacs, на C++ пишу нечасто. (kost_bebix)
12. Какие еще инструменты для C++ используются. Слышал про valgrind как хороший memory-leak детектор.
> ИДЕ — KDevelop, Eclipse, есть отладчик gdb. Дальше надо тоже конкретно смотреть «что надо». (kost_bebix)
13. Какая русская кодировка используется в Линукс системах «по умолчанию»? Поддерживает ли ядро Линукс UNICODE? На каком уровне?
> UTF-8 сегодня — это умолчальная. Сделать умолчальной практически без труда можно любую кодировку, хоть CP866. (xtreme)
14. Какое наиболее доступное решение, чтобы запустить Linux на машине с Windows? Как насчет portable Ubuntu? Кто-нибудь пользуется, можно ли вести полноценную разработку?
> Самое лучшее решение — запустить Linux внутри виртуальной машины. Я рекомендую для этого использовать VirtualBox.
> Вам уже посоветовали VMWare и VirtualBox. Последний бесплатен (xtreme)
> LiveCD ) а вообще — virtualbox. Wubi\portable Ubuntu portable — не лучший вариант. (inkvizitor68sl)
> Что значит запустить Линукс? Самое простое решение — удалить Виндоус и установить Убунту (kost_bebix)
Вопросы пользователям-программистам C++.
a1. Каким дистрибутивом лично Вы пользуетесь и почему выбрали именно его?
> Debian, привычка. Очень давное начал им пользоваться и менять не хочется. Пробовал gentoo (прикольно, но все из исходников это долго), centos/fedora (не люблю rpm) (sl_bug)
> Ubuntu. Меньше всего проблем с настройкой дистрибутива, хороший менеджер пакетов, часто обновляется. Еще неплохи (для пользователя) Fedora, OpenSUSE и большинство производных Ubuntu. (Evgeny_Shiryaev)
> Debian, Ubuntu. Последний работает из коробки почти со всем железом, первый — просто хороший неперегруженный дистрибутив, который я ставлю на сервера и на котором развёртываю только необходимый набор пакетов. (Arceny)
> Mandriva Linux. Так сложилось исторически 🙂 Некоторые считают его дистрибутивом для домохозяек, и в чем-то они правы 🙂 (GooRoo)
> Убунту. Просто из-за популярности все разрабатывается (и так и должно быть) и пилится в первую очередь под него. (kost_bebix)
a2. С помощью каких инструментов ведет разработку (если ведете)?
> vim, gcc, gdb (sl_bug)
> Qt + Qt Creator, ибо лучше ничего нет, а до vim c emacs еще не дорос. (GooRoo)
> Наверное вел бы с помощью QtCreator, если бы не подсел на Емакс. (kost_bebix)
a3. Что устраивает и что не устраивает в вашем Линуксе как программиста С++?
> Не нравится: модель межпроцедурной оптимизации в gcc (не ускоряет), стандартные оптимизации -O2 (приходится свои дописывать, либо -O3), каскадные сообщения об ошибках в boost и подобных библиотеках. (Lockal)
> Linux — лучшая операционная система в которой я работал, но для разработки на С++ по сравнению с виндой совсем непригодна. Хотя при желании… 😉 (GooRoo)
Если нетрудно — перед ответом ставьте номер вопроса, на который отвечаете. И не холиварьте чрезмерно (я знаю что хочу невозможного :).
Источник
