Сумісність офісних пакетів Linux із Microsoft Office. Яка операційна система краща – Windows чи Linux? Linux сумісний з windows
( 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 використовує стандартну схему розділів диска та може розділяти жорсткий диск з іншими системами, зокрема. з DOS.
Є завантажувач, який дозволяє вибірково завантажувати потрібну ОС із диска.
Підтримка файлових систем інших операційних систем.
З Linux звичайним чиномможна працювати з розділами жорстких дисків та дискетами, які містять файлові системи інших ОС, у т.ч. DOS, Windows 95, Minix, Xenix, Coherent, файлові системи System V. Файлові системи DoubleSpace, HPFS-2 (OS/2) та Amiga доступні лише читання.
Файлові системи DoubleSpace/Stacked тощо. стають доступними для читання і запис у Linux під час роботи емулятора DOS .
Файлова система Linux підтримує всі стандартні формати CD ROM.
Linux може бути як клієнтом, і сервером мережевої файлової системи NFS . Linux підтримує протоколи NCP та SMB і може служити файлсервером або отримувати доступ до файлосерверів NetWare та Windows for Workgroups, Windows NT.
Встановлення Linux у розділі DOS.
Linux підтримує файлову систему UMSDOS, що дозволяє встановлювати Linux прямо у файлову систему DOS без переробки розділів на жорсткому диску.
На базі UMSDOS побудований 4-х дискетний дистрибутив Mini-Linux, який встановлюється у файлову систему DOS.
Робота із дискетами у форматі DOS.
З Linux можна читати та записувати дискети DOS. Це робиться як звичайними засобами Linux (тоді дискета монтується як частина файлової системи), і спеціальними командами обслуговування дискет DOS. Також дискети доступні в емуляторі DOS.
Виконує прикладні програми DOS.
У Linux працює система dosemu – емулятор DOS. Ця програма дозволяє виконувати в Linux систему DOS, у якій зазвичай працюють прикладні програми DOS. Можна виконувати багато програм DOS, але не все. Наприклад, емулятор DOS дозволяє працювати з
- інформаційними базами даних:
- Консультант +,
- Пульс цін
- Оптовики Росії,
- та ін.;
- програмними комплексамизавдань із бухгалтерського обліку.
Програми DOS, що працюють у Linux, можуть використовувати файлову систему як розділу DOS, так і файлову систему Linux, в т.ч. мережну файлову систему NFS.
DOS виконується паралельно з іншими процесами. Можна одночасно виконувати кілька програм DOS.
Робота з програмами MS Windows.
У стадії розробки знаходиться система WINE, яка дозволяє запускати в X Windows прикладні програми MS Windows. При цьому система MS Windows не використовується та її наявність не потрібна. В даний час WINE дозволяє виконувати обмежену кількість програм MS Windows. Такі популярні програми як Word, PageMaker, CorelDraw поки що не працюють із системою WINE. Проект WINE інтенсивно розвивається, і ці та інші програми через деякий час можна буде використовувати у X Windows.
У емуляторі DOS можна виконувати MS Windows 3.0 у реальному режимі та відповідні програми. MS Windows 3.1 і Windows for Workgroups працюють в емуляторі версії 0.63, хоча для цих цілей dosemu поки що слід розглядати як альфа-версію. Емулятор DOS швидко розвивається.
Фірма Willows Software, Inc. розробила комерційну систему TWIN XPDK. Ця система містить компоненту, функціонально аналогічну WINE, за допомогою якої у X Windows працюють програми Microsoft Office Applications, Word, Excel та Project. В цілому TWIN XPDK це набір засобів для розробника MS Windows додатків (в т.ч. для Win95), який дозволяє розробнику без додаткових зусиль переносити програми між рядом платформ, включаючи Unix, OS/2, Mac.
Фірма Caldera, Inc. , стартовий капітал якої становили інвестиції Noorda Family Trust, Inc. (Ray Noorda – колишній головний керуючий фірми Novell), продає систему Caldera Network Desktop, засновану на Linux. Caldera придбала у фірми SunSoft, Inc ліцензію на Wabi – комерційну систему функціонально аналогічну до вільної системи WINE. За ціною трохи більше $200 Wabi буде поставлятися у складі диска Caldera Solutions CD.
Виконує програми з різних версій Unix.
За допомогою емулятора iBCS2 система Linux дозволяє виконувати програми, що завантажуються з систем SCO Unix, Xenix V/386, SVR3 generic, Wyse V/386, SVR4 (Unixware, USL, Dell), BSD/OS, FreeBSD. Наприклад, у Linux працюють такі програми SCO Unix як CorelDraw, WordPerfect, Oracle.
У Linux (і назад) легко переносяться на рівні вихідних текстів програми із систем Unix System V та BSD.
Linux підтримує стандарти відкритих систем, зокрема. POSIX. Світовий лідер з питань стандартизації інформаційних технологій та власник торгової марки UNIX компанія X/Open надала ОС Linux сертифікат стандарту POSIX.1 FIPS151-2. Це означає офіційне визнання того факту, що практично всі Unix-програми можуть бути без проблем переносні в Linux. Не за горами сертифікація щодо POSIX.2, POSIX.4 та POSIX.7. Компанія Lasermoon, що випускає дистрибутив Linux-FT, має членство у X/Open.
Час від часу купується нове обладнання, і, звичайно, хочеться, щоб він працював у 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/ - база даних підтримки таких порочних пристроїв, як вин-модемы.У них вся основна діяльність перекладається на драйвер, написаний під ви-самі-знаєте-яку-систему. Як наслідок, на пристрої "мозків" майже немає, як їх немає і у виробників таких пристроїв. Зусиллями вільних програмістів багато з цих пристроїв можна змусити працювати в Лінукс.
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. Гравці цього ринку конкурували не тільки з іншими типами операційних систем, але й один з одним, вводячи приватні розширення та закриті інтерфейси, обмежуючи коло можливих програм будь-яким одним клоном.
ОС Linux, що з'явилася на початку 90-х років, увібрала в себе код, створений в рамках руху 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. Вони можуть бути fixed with 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-систем
Розщеплення Linux на безліч дистрибутивів, безперечно, має місце. Але подивимося, «чи страшний чорт», спочатку відповівши питанням, що таке Linux. Насамперед, це, звичайно, ядро. І ядро це розробляється в рамках єдиного проекту, поступово акумулюючи в собі гілки та латки безлічі розробників, і жодної тенденції до фрагментації системи на рівні ядра поки що не простежується. Далі - комплекс системного оточення: засоби завантаження та ініціалізації системи; утиліти підтримки функціональності ядра; засоби підтримки взаємодії користувача із системою; загальносистемні бібліотеки; засоби підтримки графічного інтерфейсу; засоби керування пакетами.
Системне оточення крім власне завантажувача, функції якого вичерпуються на старті системи і ніяк не впливають на подальшу роботу, включає також набір сценаріїв ініціалізації системи та їх конфігураційних файлів. Ці набори специфічні для кожного дистрибутива, однак будь-який з них забезпечує завантаження всіх необхідних для подальшої роботи стартових сервісів - більше від них нічого і не потрібно.
Утиліти підтримки функціональності ядра, засоби підтримки взаємодії користувача з системою та загальносистемні бібліотеки - все це набір програм (він може бути названий Base Linux), що походить переважно з проекту GNU і споріднених йому, практично ідентичний у всіх поширених дистрибутивах і синхронно в них оновлюється . Тож і тут жодної особливої фрагментації немає.
Засоби підтримки графічного інтерфейсу – це система X Window, менеджери вікон та інтегровані робочі середовища разом із бібліотеками, на яких вони засновані. Перша зараз практично у всіх дистрибутивах Linux(і в більшості Unix-подібних систем взагалі) представлена єдиною реалізацією – Xorg. Звичайно, і тут бувають версійні відмінності, але вони позначаються лише на підтримці додаткових декоративних функцій.
Залишаються засоби управління пакетами, і тут, звичайно, специфічність дистрибутивів проявляється більшою мірою, ніж у наборі засобів ініціалізації. Власне сама специфіка дистрибутивів і визначається принципами їх комплектації.
З точки зору «базових виробників» існує лише три повністю оригінальні історично системи: 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, є досягнення повної функціональності батьківської системи, в тому числі і з точки зору сумісності зі сторонніми додатками. І по-третє, запуск пропрієтарних програм у системах, для цього начебто не призначених, часто можна досягти за допомогою спеціальних прийомів.
Залишіть свій коментар!
