Linux совместимые системы. Совместимость Linux: есть ли проблема? Выполнение прикладных программ DOS
26.02.2007 Алексей Гриневич, Денис Марковцев, Владимир Рубанов
Если вернуться в конец 90-х и окунуться в мир операционных систем того времени, то вряд ли у кого возникнет сомнение в безраздельном царствовании Unix-совместимых систем. На стороне Unix все — семейство этих операционных систем изучают в университетах, для него созданы сотни тысяч приложений, оно успешно применяется в различных отраслях экономики, о нем написано море книг и документации. Правда, нельзя приобрести именно Unix, а можно купить IBM AIX, BSD, HP-UX, Sun Solaris и т.д. При этом требуются дополнительные усилия для того, чтобы программа, созданная, скажем, для AIX, заработала под Solaris. Различные клоны Unix оказались слабо совместимы. Аналогичные проблемы имеются сегодня и для ОС Linux.
Для решения инфраструктурной проблемы слабой совместимости различных версий Unix в 1985 году в рамках IEEE была начата работа над стандартом, обеспечивающим переносимость программного обеспечения. В 1990 году увидел свет стандарт IEEE 1003, также получивший название POSIX , который регламентировал программные интерфейсы (API) и перечень команд Unix-клонов. Однако для игроков рынка Unix унификация породила сложные политические проблемы: любое решение, любой выбор между альтернативными вариантами для достижения согласия ведет к тому, что «более стандартным» признается решение одного производителя по сравнению с решением другого. В результате стандарт изобилует многозначными утверждениями типа «в данном случае возможен один из двух альтернативных вариантов поведения» и белыми пятнами наподобие «стандарт не регламентирует поведение функции в этом случае». В конце концов, фрагментация стала одной из основных причин поражения мира Unix. Игроки этого рынка конкурировали не только с другими типами операционных систем, но и друг с другом, вводя частные расширения и закрытые интерфейсы, ограничивая круг возможных приложений каким-либо одним клоном.
Появившаяся в начале 90-х годов ОС Linux, вобравшая в себя код, созданный в рамках движения GNU, и впитавшая основные идеи Unix, благодаря открытости и независимости стала универсальным компромиссом. Ее код реализовывался с нуля, не опираясь на какую-либо реализацию, а только на текст стандарта POSIX. В результате система получилась изначально POSIX-совместимой, а независимость позволила объединить усилия различных игроков рынка Unix в борьбе за «возврат» упущенного сегмента операционных систем для ПК. Однако проблема фрагментации осталась актуальной и для Linux: наличие конкурирующих между собой дистрибутивов вызывает опасения в вероятном повторении судьбы Unix.
На первый взгляд, сама опасность фрагментации выглядит довольно призрачной - фактически имеется общий код, большинство дистрибутивов работают на основе одного и того же ядра, одних и тех же библиотек, что во многом определяет совместимость. Казалось бы, и приложения должны сохранять работоспособность и совместимость между различными версиями Linux. Но это не получает подтверждения на практике. Наряду с фрагментацией рынка дистрибутивов Linux по подходам и дополнительной функциональности, наблюдаются существенные перекосы в поддержке различными клонами даже распространенных и стандартных приложений - в различных дистрибутивах используются разные версии ядра и системных библиотек (в первую очередь, glibc). Это ведет к тому, что состав и поведение системных интерфейсов, предоставляемых системой приложениям, меняются от дистрибутива к дистрибутиву. Для того чтобы не повторить печальный опыт клонов Unix, в 1998 году в рамках специально созданной организации Free Standards Group (сейчас Linux Foundation ) началась работа над стандартом 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
Каждая конкретная Linux-система создается для работы одного или нескольких приложений, однако кода самого приложения недостаточно, чтобы извлечь необходимый пользователям сервис из аппаратуры - большинство приложений использует в своей работе обращения к функциям библиотек. Стандарт LSB Core 3.1 определяет следующие системные библиотеки: libc, libcrypt, libdl, libm, libpthread, librt, libutil, libpam, libz, libncurses. В современных Linux-системах интерфейсы этих системных библиотек реализуются библиотеками glibc, Linux-PAM, zlib и ncurses, которые на самом деле реализуют больше интерфейсов, чем определено в LSB Core.
По степени взаимодействия с ядром Linux функции системных библиотек можно классифицировать так:
- реализация функции полностью содержится в библиотеке, и ядро не используется (например, strcpy, tsearch);
- в библиотеке реализуется тривиальная «обертка» (wrapper) для вызова соответствующего интерфейса ядра (например, read, write);
- реализация функции содержит как вызовы системных интерфейсов ядра (причем возможно нескольких разных), так и часть кода в самой библиотеке (например, pthread_create, pthread_cancel).
Само ядро Linux содержит много экспортируемых точек входа, однако подавляющее большинство из них является внутренним интерфейсом для использования модулями и подсистемами самого ядра. Внешний интерфейс содержит порядка 250 функций (версия 2.6). Из них, к примеру, в своей реализации библиотека glibc 2.3.5 использует 137.
Конфигурации
Под конфигурацией системной части дистрибутива понимается комбинация версии ядра (включая отдельные заплаты), версий системных библиотек, параметров их сборки и архитектуры, на которой это все работает. На приведен пример конфигурации сборки двух гипотетических дистрибутивов, представляющих собой совокупность версий компонентов и заплат. Между версиями компонентов добавляется новая функциональность, а также убираются морально устаревшие интерфейсы и функции. Так, на данной диаграмме легко видеть, что поскольку дистрибутивы 1 и 2 используют различные версии GCC, совместимость по исходным кодам между ними отчасти утеряна - не все, что собиралось с помощью gcc 3.4, может быть собрано с помощью gcc 4.0 без доработки.
Рис. 2. Пример конфигурации сборки дистрибутивов
Дистрибутивы
По адресу lwn.net/Distributions/ можно найти перечень известных дистрибутивов Linux (на момент написания статьи их было 542), открытых для широкой публики. Здесь не учитываются версии, сделанные для внутреннего применения индивидуальными энтузиастами, а также различными компаниями, ведомствами и т.п. Согласно лицензии GNU, можно взять произвольный дистрибутив, внести в него модификации (как минимум в компоненты, подпадающие под GNU) и распространять далее.
Дистрибутивы можно классифицировать по ряду признаков.
- По базовым производителям. К примеру, Red Hat, Slackware, SuSE, Debian, Asianux, Mandriva, Gentoo представляют собой основные «ветви» Linux-индустрии. Эти дистрибутивы не являются наследниками других (хотя между ними есть некоторые исторические зависимости). Их можно считать стратегическими направлениями развития в Linux вообще. Большинство остальных дистрибутивов явно принадлежат к одной из упомянутых ветвей, - в основном наследуя исходный код и приложения и добавляя специфическую функциональность.
- По локализации. Во многих странах присутствует локальный производитель Linux (скажем, в России всем известны дистрибутивы ASP Linux и ALT Linux).
- По применению. Дистрибутивы для встроенного применения в мобильных устройствах; дистрибутивы, работающие без поддержки файловой системы; облегченные версии для использования в КПК; переносные версии для запуска с ограниченных носителей (Linux на дискете, Linux на компакт-диске и т.п.).
- По специализации. Дистрибутивы для поддержки определенной аппаратной архитектуры (AlphaLinux с поддержкой процессорной архитектуры Alpha, ARM Linux с поддержкой ARM и т.п.).
Процедура сборки Linux
Может показаться, что для достижения надежности и совместимости на уровне поведения интерфейсов системных библиотек достаточно, чтобы тестирование проводилось разработчиками ядра и библиотек, однако это не так. Уже на уровне интерфейсов системных библиотек существует масса измерений, которые делают практически каждую Linux-систему уникальной с точки зрения качества. Поведение интерфейсов для приложений определяется комбинацией из библиотек, ядра и аппаратуры. В свою очередь ядро и библиотеки определяются своей версией (включая официальные или неофициальные заплаты и модификации) и, что очень важно, конфигурацией сборки.
Многообразие различных входящих в Linux компонентов и множество зависимостей между ними может проиллюстрировать процедура сборки ядра. Проект Linux From Scratch содержит последовательность шагов, необходимых для сборки дистрибутива Linux «с нуля». Упрощенная последовательность сборки дистрибутива LFS Linux версии 6.0 выглядит так:
1. Binutils-2.15.94.0.2.2 - Pass 1
2. GCC-3.4.3 - Pass 1
3. Linux-Libc-Headers-2.6.11.2
4. Glibc-2.3.4
…
87. Util-linux-2.12q
88. Конфигурация загрузки
89. Linux-2.6.11.12 - Ядро
Сборка ядра осуществляется на самом последнем шаге с помощью собранных перед этим бинарных утилит. Важно учитывать версии компонента, приведённого в каждом элементе списка. Замена одной версии компонента на другую не всегда тривиальна - сборка системы может оказаться невозможной из-за отсутствия или изменения какой-либо функции, либо усложнена. Сборка многих компонентов требует дополнительных действий, например, инструкция по сборке flex для данного дистрибутива содержит замечание :
Flex contains several known bugs. These can be fixed with the following patch:
patch -Np1 -i ../flex-2.5.31-debian_fixes-3.patch
В процесс сборки включается сборка средств компиляции, которые также претерпевают существенные изменения во времени. Даже базовые компоненты Linux нередко оказываются устаревшими. Так, версия компилятора gcc 4.0.0 не годится для сборки ядра 2.6.11 (хотя они и современники) и требует использования специальной заплаты для устранения этой несовместимости.
В плену зависимостей
Фрагментация на уровне библиотек - серьезнейшая проблема современного мира Linux. Частый выход новых версий библиотек Linux обычно считается хорошим явлением и, действительно, только так возможно быстро применять и апробировать новые идеи и делать доступными последние достижения «инженерной мысли»: в широком использовании иногда находятся десятки версий одной и той же библиотеки. При этом неотъемлемой отличительной чертой разработки отдельных компонентов ОС Linux является ее децентрализованный характер. Часто почти одновременно вышедшие новые версии различных компонентов заведомо несовместимы, а это означает, что совершенно невозможно обеспечить адекватное тестирование различных комбинаций библиотек на совместимость и гарантировать стабильную работу системы при всех возможных комбинациях. Как следствие, вся тяжесть проблем ложится на пользователя, решившегося установить программу или библиотеку, для которой явно не гарантируется способность работы в окружении, существующем на его машине, и такая ситуация складывается довольно часто.
Категория проблем, связанных с несовместимостью версий библиотек, получила название dependency hell («ад зависимостей», en.wikipedia.org/wiki/Dependency_hell ). С какими проблемами может столкнуться пользователь, установивший в свою версию ОС Linux какую-либо новую библиотеку? В этом случае приложения, работавшие с предшествующей версией, могут перестать корректно функционировать, так как эти приложения могли полагаться явно или неявно на определенные ошибки и побочные эффекты, присутствовавшие в старой версии. Также вполне реальна обратная ситуация, когда новая версия просто содержит новую ошибку. Но настоящая проблема возникает тогда, когда в системе должны работать несколько различных приложений, которые существенно полагаются на различные версии одной и той же библиотеки; может так оказаться, что совместная работа этих приложений просто невозможна. Иногда существует возможность иметь несколько версий одной и той же библиотеки в системе, и это будет вполне безопасным решением, однако это совершенно не рекомендуется делать в случае библиотеки glibc.
Основной эволюционный путь к достижению совместимости различных дистрибутивов Linux - стандартизация . Зрелый и всесторонне поддерживаемый стандарт позволит снизить затраты на обеспечение переносимости Linux-решений, что будет способствовать росту числа приложений для этой платформы, а значит и популярности Linux в целом. Сегодня в качестве такого «спасительного» стандарта выступает Linux Standard Base .
LSB - основной стандарт, определяющий требования совместимости к Linux-системам. Основные сведения по этому стандарту уже публиковались, например, в работе , в которой, однако, освещалась старая версия стандарта и несколько преувеличивалась роль интерфейсов ядра. В действительности стандарт LSB не специфицирует интерфейсы ядра, а определяет более высокоуровневые прикладные интерфейсы, реализуемые различными библиотеками. LSB не пытается быть заменой существующих стандартов, а наоборот, опирается на все основные стандарты, уже прижившиеся в Linux. Он фиксирует версии и подмножества составляющих стандартов, чтобы обеспечить согласованность, и дополняет описания тех интерфейсов, которые присутствуют де-факто в большинстве дистрибутивов Linux, но не вошли в какие-либо существующие стандарты. Основную часть стандарта LSB составляют требования к системным интерфейсам, которые должны поддерживаться всеми дистрибутивами Linux (своего рода «общий знаменатель» всех Linux-систем). В этой части LSB во многом ссылается на стандарт POSIX.
Основное отличие LSB в том, что разработчики приложений могут ориентироваться на одну платформу, скажем LSB 3.1, и этого достаточно для обеспечения работы на всех совместимых с LSB 3.1 дистрибутивах. То же самое действует и для поставщиков дистрибутивов: как только достигнуто соответствие с LSB 3.1, автоматически дистрибутив поддерживает все совместимые с ним приложения. К примеру, IBM в рамках инициативы Chiphopper предоставляет аппаратные решения под управлением только LSB-совместимых дистрибутивов. Во многом благодаря активности крупных игроков основные поставщики дистрибутивов уже прошли сертификацию по LSB или объявили о своих намерениях сертифицироваться (www.linux-foundation.org/en/LSB_Distribution_Status ).
Сейчас основной слабостью стандарта LSB является недостаток тестов. Встречаются случаи, когда описанный в стандарте интерфейс работает иначе, и тем не менее система успешно проходит сертификацию. Это объясняется тем, что теста на данный интерфейс просто нет, либо он слишком слаб, чтобы полноценно проверить работоспособность интерфейса. Очень уместно процитировать высказывание Яна Мердока, создателя Debian, а сегодня директора по технологиям Linux Foundation: «Известно, что интерфейсный стандарт хорош настолько, насколько хорошо тестовое покрытие, которое проверяет соответствие этому стандарту».
В Open Group открыли для включения в сертификационный набор тестов LSB некоторые из своих тестов для стандарта POSIX. В набор LSB включены свободные тесты стандартной библиотеки GNU C++ Runtime Library Test Suite, адаптированы тесты для libgtk и libxml. Консорциум Linux Foundation рассматривает возможность выкупа для открытия и включения в LSB различных платных тестовых наборов.
Занимаются решением этой задачи и в нашей стране. Так на базе Института системного программирования РАН создан Центр верификации ОС Linux, где разрабатывается открытый тестовый набор OLVER, который планируется включить в официальные тесты LSB. Между Центром и Linux Foundation заключено соглашение о сотрудничестве, в рамках которого продолжаются работы по улучшению тестового покрытия LSB и идет разработка новой инфраструктуры для развития этого стандарта.
Заключение
Для того чтобы предотвратить фрагментацию, уже имевшую место в отношении ОС Unix, необходимы меры обеспечения совместимости дистрибутивов - по крайней мере, в рамках некоторого подмножества функциональности. Переносимость приложений в рамках этого подмножества позволит объединить Linux как единую платформу и заметно понизить стоимость разработки и поддержки приложений, что должно положительно сказаться на их количестве и популярности Linux-решений в целом.
Сегодня основной инициативой по обеспечению переносимости является открытый стандарт LSB, принятый ведущими производителями дистрибутивов (Red Hat, SuSe, Mandriva) и приложений (MySQL, RealPlayer, SAP MaxDB). За этим стандартом стоит мощный консорциум Linux Foundation и такие его активные члены, как компании IBM, Intel, HP и Oracle, что позволяет надеяться на его успешное развитие и повсеместное внедрение в реальную жизнь. Таким образом, в лице стандарта LSB заложен надежный фундамент единой, нефрагментированной платформы Linux, обеспечивающей переносимость приложений как на основе исходного кода, так и в бинарном виде.
Однако даже очень хорошие стандарты остаются лишь благими пожеланиями, пока нет удобных и надежных способов проверять соответствие им. Именно поэтому улучшение качества покрытия тестов LSB является одним из важнейших приоритетов сотрудничества Центра верификации ОС Linux и Linux Foundation.
Тестовый набор основан на автоматической генерации тестов из формальных спецификаций требований и соответствующих тестовых сценариев с применением технологии UniTESK.
К концу 2006 года основная фаза проекта была завершена; все результаты проекта опубликованы на сайте Центра. Сейчас проект находится в стадии поддержки и расширения спектра целевых платформ (комбинации аппаратной архитектуры с конкретным дистрибутивом).
* Flex содержит несколько известных ошибок. Они могут быть исправлены при помощи следующей заплаты…- англ.
Проблемы совместимости Linux-систем
( 2007-08-15 )
Чтобы принять решение, относительно того, сможет ли некоторый компьютер замечательно работать под Linux или же нет, нужно проверить все его компоненты - видеокарту, звуковую карту, принтер, сканер, цифровую камеру и прочие устройства на совместимость с Linux.
Конечно за последнее десятилетие поддержка различных аппаратных средств в Linux заметно улучшилась и сейчас у вас есть достаточно большой шанс купив компьютер без каких либо проблем запустить на нём практически любой дистрибутив. Однако всё-таки есть и оборудование, которое в настоящий момент не поддерживается.
Сегодня практически всё оборудование работает хорошо, однако вам стоит опасаться оборудования, которым управляют при помощи программ а не кнопок. Потому что программы скорее всего написаны для Windows и иногда для Mac OS X.
Даже когда изготовитель делкларирует поддержку Linux - будьте очень осторожны. Скорее всего вам придётся отправится на сайт изготовителя, где, весьма вероятно, вы найдёте не совсем свежую информацию. Поиск по интернету тоже не будет очень полезен, поскольку в итоге даст множество страниц с устаревшей или не совсем верной в вашем случае информацией.
Ниже следует перечисление некоторых интернет-ресурсов, информация на которых регулярно обновляется и является достаточно полной и подробной.
Видеокарты
Если вы хотите проверить поддерживается ли ваша видеокарта - начните с сайта X.Org , там есть список поддерживаемых видеокарт. Так же вы можете проверить сайт изготовителя. Это актуально например для видеокарт от NVIDIA и ATI . Кроме того существует проект Nouveau , который разрабатывает открытые драйвера для карт NVIDIA, и его собрат - проект Avivo , разрабатывающий открытые драйвера для карт ATI. Однако ни один из этих проектов пока ещё не представил официального релиза.
Если вы не знаете что лучше выбрать - открытые драйвера или проприетарные - есть несколько способов сделать этот выбор. Во-первых вы можете сделать выбор основываясь на своей философии, однако скорее всего выбор будет делаться на основе их функционала. Основная проблема открытых драйверов - ограниченная, или полностью отсутствующая поддержка 3D-возможностей, в то время как проприетарные драйвера грешат медлительностью и (особенно ATI) нестабильностью в работе.
Ещё один вариант - политика исползуемого вами дистрибутива. В коммерческие дистрибутивы вроде Xandros и Linspire обычно уже включены проприетарные драйвера, в то время как в Ubuntu используются открытые. Правда в Ubuntu есть ещё и Restricted Device Manager , позволяющий легко установить проприетарные драйвера в систему. Fedora 7 - один из первых дистрибутивов, по возможности использующий драйвера Nouveau вместо проприетарных драйверов NVIDIA.
Звуковые карты
К сожалению не существует единого сайта с подробной информацией, однако вы можете ознакомится со списком Linux-совместимых карт на сайте Linux-Sound. Так же вы можете почерпнуть информацию из листов рассылки Linux Audio Developers .
Ещё один неплохой источник - Soundcard Matrix на сайте проекта ALSA. Если ваша карта есть в этой матрице, и столбец Notes пуст - ваша карта гарантированно поддерживается.
Принтеры
У вас гарантированно будет работать любой принтер, поддерживающий универсальный язык PostScript. Однако если вы хотите получить более подробную информацию начните с базы совместимости принтеров , которая является частью проекта OpenPrinting (Бывший LinuxPrinting.org).
База совместимости принтеров - почти идеальный источник информации по принтерам. Она содержит в себе практически все известные принтеры. Для каждого принтера в ней выставляется свой уровень поддержки: Хорошо, В основном, Частично и Пресс-папье:). Так же база описывает с каким драйвером какой принтер как работает, и детальное описание настроек для полного использования принтера. Как альтернатива - вы можете выбрать принтер под свои задачи, используя часть всё той же базы данных . Вся информация основана на сообщениях пользователей..
Сканеры
Если в качестве сканера вы используете многофункциональный принтер то вам может помочь база данных по принтерам (см. предыдущую главу). Однако основной источник информации о совместимости сканеров - служба поиска информации проекта SANE , которая поможет вам найти информацию о пригодности конкретной модели для использования в Linux. При возникновении проблем, лучше всего задавать вопросы на форуме проекта SANE.
Цифровые камеры
Современные цифровые камеры отказались от закрытых протоколов прошлого в пользу открытого - USB, поддержка которого в Linux находится на очень высоком уровне. Однако если вам всё же нужно удостовериться что ваша камера будет поддерживаться - обратитесь к проекту gPhoto , база данных которого насчитывает более девятисот наименований. Другой источник - база Хьюберта Фигуиера (Hubert Figuiere) , которая содержит детальную информацию не только о поддержке камер, но и о конфигурировании системы для использования их.
Беспроводные адаптеры
Несколько лет назад основным пробелом в поддержке устройств были модемы. В наши дни это беспроводные адаптеры. Кроме того постоянные выходы новых моделей ещё более усложняют поддержку. Так например две родственных модели могут иметь принципиально разные прошивки и соответственно требовать различных драйверов.
Единственный своевременно обновляющийся сайт с информацией по беспроводным адаптерам - , поддерживаемый Жаном Тоеррилхесом (Jean Tourrilhes) при спонсорской поддержке Hewlett-Packard. Информация на сайте размещена достаточно хаотично, однако при желании разобраться в ней можно.
Если ваш адаптер не поддерживается, возможно у вас получится запустить его с помощью , или, для адаптеров Broadcom, - . Оба эти проекта фактически представляют из себя обёртку для драйверов из Windows или Mac OS X.
Недостатком обеих программ является необходимость использования lspci для получения Bus ID вашего адаптера. Поэтому прежде чем что-то покупать - посмотрите сколько адаптеров, подобных вашему, поддерживает ndiswrapper.
Ноутбуки и прочие мобильные устройства
Время от времени покупается новое оборудование, и, конечно, хочется, чтобы он работало в Linux. Не то, чтобы свободное сообщество не умеет или не хочет поддерживать устройства — опыт показывает, что как раз может и умеет. Дело в жадных и глупых производителях, которые не хотят не только писать драйверы для своих железок, но и даже открывать спецификации на свои устройства. Обычно, если оборудование не работает в Linux, то такой производитель, как правило, вообще не заслуживает внимания.
В этом посте говорится о Linux и установке оборудования в линукс. Установить оборудование в Linux легко, и ниже приводится информация о ресурсах, которые в этом помогут.
Где найти информацию по совместимости устройств и периферии с Linux?
http://linux-wless.passys.nl/ — расширенная база WiFi-карт для Linux.Это самый полный ресурс по поддержке беспроводных сетевых карт в Linux, можно смотреть по производителям — и если поддерживается, то сразу даётся название драйвера.
http://www.sane-project.org/sane-mfgs.html — список сканеров в Линукс, которые поддерживаются подсистемой SANE. Список по моделям сканеров, работающих в Linux в зависимости от изготовителя. Градации совместимости: полная поддержка, частичная, базовая, нет поддержки. Также указывается, какой требуется backend для работы устройства.
http://openprinting.org/printer_list.cgi — база данных работающих принтеров в Линукс, поддерживаемых подсистемой печати CUPS, которая предоставляет в Linux драйвера для принтеров в Linux-дистрибутивах. Удобный поиск по моделям принтеров и по изготовителю. Градации совместимости: работает, работает почти, работает ограниченно, балласт.
Базы данных по категориям устройств
http://www.linuxcompatible.org/compatibility.html — база данных по всем устройствам, совместимых с Linux, начиная от звуковых карт и заканчивая принтерами и сканерами. Есть градации совместимости: работает отлично, работает большей частью, работают некоторые функции, балласт. База весьма обширна, время от времени обновляется создателями сайта. В любом случае, замечательный ресурс.
http://kmuto.jp/debian/hcl/ — база устройств, поддерживаемом ядрами 2.6.15 и выше. Просто копируем вывод lspci -n из консоли и получаем сведения о поддержке железа, находящегося на материнской плате.
http://www.linux-laptop.net/ — самый полный ресурс о работе Linux на ноутбуках. На странице приведена классификация по производителям, дальше — ссылки по моделям на конкретные страницы пользователей, рассказывающих, что и как они предпринимали для получения функциональности своих ноутбуков. Большинство информации на английском, но другие языки также присутствуют.
http://start.at/modem — большой ресурс по поддержке таких ущербных устройств, как винмодемы. Оказывается, из этого балласта тоже можно кое-что извлечь: приведён внушительный список поддерживаемых устройств.
http://www.phoronix.com/lch/ — пользовательская база данных поддерживаемых устройств. Начинает наполняться, вы тоже можете принять в этом участие. Есть RSS-потоки как по конкретному виду железяк, так и по всем сразу.
— замечательный ресурс по устройствам в Линукс со ссылками на HOWTO и «как настроить». На странице — классификация по типам устройств, далее — ссылки на то, как настроить и какие могут возникнуть проблемы. Так же имеются ссылки на общую информацию по данным устройствам. Очень познавательно. Есть -лента на новости сайта (новая документация).
http://cdb.suse.de/?LANG=en_UK — список устройств, совместимых с SuSE Linux. Обновляемая база совместимых устройств с SuSe Linux. Как правило, и в других дистрибутивах эти устройства работают тоже.
http://www.linuxtested.com/ — совместимость и работа устройств по дистрибутивам. На сайте есть информация о тестировании устройств в следующих дистрибутивах: SuSE, Redhat / Fedora, TurboLinux, Debian, Mandrake.
http://www.linux.org/hardware/ — аппаратура, работающая в Linux.Список не полон, но может быть полезен — есть информация об экзотическом железе, для которого есть поддержка в Linux.
http://www.linux-drivers.org/ — ссылки на множество ресурсов, посвящённых совместимости с Linux. Большое количество ссылок на ресурсы и поддержке железа в Linux.
http://hardware4linux.info/ — каталог linux-совместимого аппаратного обеспечения, деление по категориям: «работает прямо из коробки», «работает с модификацией», «неизвестно», «работает частично» и «не работает». Достаточно большая и постоянно обновляемая база данных по устройствам.
http://www.linmodems.org/ — база данных по поддержке таких порочных устройств, как вин-модемы. В них вся основная деятельность перекладывается на драйвер, написанный под вы-сами-знаете-какую-систему. Как следствие, на устройстве «мозгов» почти нет, как их нет и у производителей таких устройств. Усилиями свободных программистов, многие из этих устройств можно заставить работать в Линукс.
Расщепление 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, то такой производитель, как правило, вообще не заслуживает внимания.
В этом посте говорится о Linux и установке оборудования в линукс. Установить оборудование в Linux легко, и ниже приводится информация о ресурсах, которые в этом помогут.
Где найти информацию по совместимости устройств и периферии с Linux?
http://linux-wless.passys.nl/ - расширенная база WiFi-карт для Linux.
Это самый полный ресурс по поддержке беспроводных сетевых карт в Linux, можно смотреть по производителям - и если поддерживается, то сразу даётся название драйвера.
http://www.sane-project.org/sane-mfgs.html - список сканеров в Линукс, которые поддерживаются подсистемой SANE. Список по моделям сканеров, работающих в Linux в зависимости от изготовителя. Градации совместимости: полная поддержка, частичная, базовая, нет поддержки. Также указывается, какой требуется backend для работы устройства.
http://openprinting.org/printer_list.cgi - база данных работающих принтеров в Линукс, поддерживаемых подсистемой печати CUPS, которая предоставляет в Linux драйвера для принтеров в Linux-дистрибутивах. Удобный поиск по моделям принтеров и по изготовителю. Градации совместимости: работает, работает почти, работает ограниченно, балласт.
Базы данных по категориям устройств
http://www.linuxcompatible.org/compatibility.html
- база данных по всем устройствам, совместимых с Linux, начиная от звуковых карт и заканчивая принтерами и сканерами.
Есть градации совместимости: работает отлично, работает большей частью, работают некоторые функции, балласт. База весьма обширна, время от времени обновляется создателями сайта. В любом случае, замечательный ресурс.
http://kmuto.jp/debian/hcl/ - база устройств, поддерживаемом ядрами 2.6.15 и выше . Просто копируем вывод lspci -n из консоли и получаем сведения о поддержке железа, находящегося на материнской плате.
http://www.linux-laptop.net/ - самый полный ресурс о работе Linux на ноутбуках. На странице приведена классификация по производителям, дальше - ссылки по моделям на конкретные страницы пользователей, рассказывающих, что и как они предпринимали для получения функциональности своих ноутбуков. Большинство информации на английском, но другие языки также присутствуют.
http://start.at/modem - большой ресурс по поддержке таких ущербных устройств, как винмодемы . Оказывается, из этого балласта тоже можно кое-что извлечь: приведён внушительный список поддерживаемых устройств.
http://www.phoronix.com/lch/ - пользовательская база данных поддерживаемых устройств. Начинает наполняться, вы тоже можете принять в этом участие. Есть RSS-потоки как по конкретному виду железяк, так и по всем сразу.
- замечательный ресурс по устройствам в Линукс со ссылками на HOWTO и "как настроить". На странице - классификация по типам устройств, далее - ссылки на то, как настроить и какие могут возникнуть проблемы. Так же имеются ссылки на общую информацию по данным устройствам. Очень познавательно. Есть -лента на новости сайта (новая документация).
http://cdb.suse.de/?LANG=en_UK - список устройств, совместимых с SuSE Linux. Обновляемая база совместимых устройств с SuSe Linux. Как правило, и в других дистрибутивах эти устройства работают тоже.
http://www.linuxtested.com/ - совместимость и работа устройств по дистрибутивам. На сайте есть информация о тестировании устройств в следующих дистрибутивах: SuSE, Redhat / Fedora, TurboLinux, Debian, Mandrake.
http://www.linux.org/hardware/ - аппаратура, работающая в Linux. Список не полон, но может быть полезен - есть информация об экзотическом железе, для которого есть поддержка в Linux.
http://www.linux-drivers.org/ - ссылки на множество ресурсов, посвящённых совместимости с Linux. Большое количество ссылок на ресурсы и поддержке железа в Linux.
http://hardware4linux.info/ - каталог linux-совместимого аппаратного обеспечения
, деление по категориям: "работает прямо из коробки", "работает с модификацией", "неизвестно", "работает частично" и "не работает". Достаточно большая и постоянно обновляемая база данных по устройствам.
http://www.linmodems.org/ - база данных по поддержке таких порочных устройств, как вин-модемы.
В них вся основная деятельность перекладывается на драйвер, написанный под вы-сами-знаете-какую-систему. Как следствие, на устройстве "мозгов" почти нет, как их нет и у производителей таких устройств. Усилиями свободных программистов, многие из этих устройств можно заставить работать в Линукс.
