Перейти до вмісту

Linux Standard Base

Матеріал з Вікіпедії — вільної енциклопедії.
Версія від 11:31, 23 травня 2010, створена 985D83E8 (обговорення | внесок) (давно вже не Core)

Linux Standard Base, чи LSB, — спільний проект кількох дистрибутивів GNU/Linux з організацією Linux Foundation, метою якого є стандартизація внутрішньої структури операційних систем, заснованих на Linux. LSB спирається на існуючі специфікації, такі як POSIX, Single UNIX Specification, та інші відкриті стандарти, розширюючи і доповнюючи їх.

Згідно проголошеної мети проекту:

Мета LSB — розробити і просувати набір стандартів, який збільшить сумісність різних дистрибутивів Linux і дасть можливість запускати застосунки на будь-якій сумісній системі. Крім того, LSB допоможе скоординувати зусилля в залученні розробників до написання і портуванню застосунків під Linux.

Щоб сертифікувати програмний продукт на сумісність із стандартом LSB, потрібно пройти сертифікаційну процедуру, яка проводиться The Open Group, що співробітничає з Free Standards Group.

LSB специфікує: стандартні бібліотеки, декілька команд і утиліт на додаток до стандарту POSIX, структуру ієрархії файлової системи, рівні запуску і різні розширення системи X Window System.

Потреба в стандартизації

Із самого початку операційна система Linux була POSIX-сумісною операційною системою за винятком невеликого числа окремих невідповідностей. Проте, це не врятувало Linux від проблем з переносимістю застосунків і подальшою фрагментацією ринку.

Недоліки POSIX стосовно такої ситуації наступні

  • інтерфейсів, специфікованих в POSIX, виявляється недостатньо для повноцінної розробки всіх видів застосунків. Якщо системні застосунки і застосунки, що взаємодіють з користувачем за допомогою терміналу, можуть бути реалізовані в рамках інтерфейсів POSIX, то застосунки з графічним інтерфейсом користувача, і застосунки, що використовують системну інформацію, виявляються поза стандартом POSIX.
  • опис вимог на рівні вихідого коду вимагає перекомпіляції застосунків. Це не є великою перешкодою при розповсюдженні застосунків з відкритими аихідими кодами, але істотно ускладнює розповсюдження застосунків в двійковому вигляді. У останньому випадку розробникові потрібно мати доступ до всіх підтримуваних дистрибутивів для збірки свого застосунку. Не легко доводиться і кінцевому користувачеві. Оскільки серед постачальників операційної системи Linux немає сталої традиції підтримувати зворотну двійкову сумісність компонентів, то будь-яке оновлення системи може привести до втрати працездатності окремих застосунків. І навіть в тих випадках, коли застосунок поставляється з вихідними кодами і користувачеві для відновлення його працездатності потрібно тільки виконати перекомпіляцію застосунку, така ситуація не приносить користувачеві нічого окрім додаткового головного болю.

Шлях, яким пішло співтовариство Linux для подолання проблем з переносимістю застосунків, полягав в стандартизації базових інтерфейсів операційної системи на бінарному рівні. Для цього в 1998 році була утворена некомерційна організація Free Standards Group, під орудою якої почалася розробка стандарту Linux Standard Base (LSB). Діяльність зі створення стандарту підтримали Лінус Торвальдс, Брюс Перенс, Ерік Раймонд, декілька постачальників дистрибутивів Linux, розробники застосунків, члени Linux International, а також Джон Габбард з проекту FreeBSD[1].

Опис стандарту

Будь-який стандарт, що описує інтерфейси на рівні двійкового коду, залежить від архітектури апаратного забезпечення, на якій має працювати двійковий код. В той же час, тільки невелика частина стандарту LSB містить вимоги, залежні від апаратної платформи. З урахуванням цього факту, а також того, що стандарт LSB підтримує декілька апаратних архітектур, текст стандарту побудований за наступним принципом.

Всі вимоги стандарту, які не залежать від цільової апаратної платформи, винесені в окремий документ, званий «Загальною специфікацією LSB». Крім того, для кожної підтримуваної платформи створений додатковий документ, що описує вимоги LSB, специфічні для даної платформи. Таким чином, повні набір вимог стандарту LSB для деякої платформи знаходиться в двох документах: у загальній специфікації LSB і в специфікації LSB для цієї платформи.

Стандарт LSB 3.2 підтримує 7 платформ:

  • AMD64 Architecture
  • IA32 - IA-32 Intel Architecture
  • IA64 - Intel Itanium Architecture
  • PPC32 - POWERPC Microprocessor Architecture
  • PPC64 - 64-bit POWERPC Microprocessor Architecture
  • S390 - IBM S/390 Architecture
  • S390X - IBM z/Architecture [S390X].

Стандарт LSB 3.2 складається з модулів: LSB Core, LSB C++, LSB Desktop, LSB Print та LSB Runtime languages. Крім того, існує додатковий, необов'язковий модуль, LSB Qt 4.

LSB Core

Базові вимоги

  • вимоги до формату виконуваних файлів;
  • вимоги до базового бінарного інтерфейсу;
  • вимоги до команд і утиліт;
  • вимоги до устрою файлової системи;
  • вимоги до процесу ініціалізації;
  • вимоги до користувачів і груп;
  • вимоги до інсталяції програмного забезпечення.

Базові вимоги включають визначення таких ключових елементів двійкового інтерфейсу як розміри базових типів мови C, угоди про виклик функцій тощо. Велика частина таких вимог визначаються в платформо-залежних документах LSB.

Вимоги до формату виконуваних файлів полягають в наступному. Операційна система зобов'язана підтримувати виконання здійснимих файлів у форматі Executable And Linking Format (ELF) з урахуванням додаткових вимог, сформульованих в стандарті LSB. LSB вимагає підтримки наступних елементів:

  • додаткових типів секцій ELF файлу;
  • формату налагоджувальної інформації DWARF 2.0;
  • версій бінарних символів;
  • процесу динамічного зв'язування.

Вимоги до базового бінарного інтерфейсу операційної системи є одним з ключових елементів стандарту. Стандарт наказує системі містити 12 розподільних бібліотек:

  • інтерпретатор программ-редактор динамічних зв'язків (ld-lsb.so);
  • бібліотека підтримки мови Сі (libс);
  • бібліотека математичних функцій (libm);
  • бібліотека потоків управління POSIX (libpthread);
  • незалежна від мови бібліотека підтримки компілятора gcc (libgcc_s);
  • завантажувач динамічних бібліотек (libdl);
  • бібліотека функцій реального часу (librt);
  • бібліотека функцій криптографії (libcrypt);
  • бібліотека модуля ідентифікації, що настроюється (libpam);
  • бібліотека функцій стиснення даних (libz);
  • бібліотека функцій термінального інтерфейсу (libncurses);
  • бібліотека допоміжних функцій (libutil).

Крім того, для кожної бібліотеки стандарт визначає набір загальнодоступних бінарних символів і описує вимоги до кожного окремого символу. У загальному вигляді вимога до бінарного символу звучить таким чином:

У розподільній бібліотеці X повинен бути присутнім бінарний символ Y (версії Z) і при використанні цього символу як функції із заданою сигнатурою його поведінка повинна відповідати вимогам стандарту.

Розробники LSB вважали за краще не дублювати опис функцій, відповідних бінарним символам, якщо в якому-небудь з існуючих стандартів дана функціональність вже специфікована. Замість дублювання тексту вони указують посилання на відповідний стандарт. І навіть якщо функціональність, реалізована в Linux-системах, відмінна від стандартизованної раніше, в LSB зазвичай стоїть посилання на інший стандарт з додатковим описом відмінностей вимог LSB від вимог початкового стандарту.

Важливою особливістю стандартів, що описують інтерфейси на рівні двійкових кодів, є фіксація значень всіх констант, а також фіксація розмірів всіх типів і зсувів полів у всіх структурах даних. Дійсно, якщо POSIX визначає, що в заголовному файлі повинні бути визначені константа із заданим ідентифікатором і структура із заданим ім'ям і набором полів, то цього виявляється достатньо для коректної роботи POSIX-сумісного застосунку. Конкретні значення констант і зсуву полів усередині структур визначаються на етапі компіляції програми. Для LSB, який стандартизує вже скомпільовані застосунки, всі ці значення повинні бути зафіксовані в самому стандарті.

Вимоги до команд і утиліт

В стандарті LSB визначають необхідність наявності і правил функціонування 5 команд і 133 утиліт. По своїй структурі опису утиліт нічим не відрізняються від опису утиліт в стандарті IEEE Std 1003.1 (POSIX), оскільки для утиліт не існує відмінності між рівнем початкових кодів і рівнем бінарних кодів.

Вимоги до устрою файлової системи

Вимоги до устрою файлової системи стандарту LSB базуються на стандарті Filesystem Hierarchy Standard (FHS) 2.3. На додаток до FHS 2.3 LSB вимагає наявність файлів пристроїв /dev/null, /dev/zero і /dev/tty, а також семи спеціальних директорій в каталозі /etc. Також стандарт LSB регламентує, щоб застосунки використовували для іменування конфігураційних файлів в директорії /etc або короткі імена, зареєстровані в Linux Assigned Names and Numbers Authority (LANANA), або, так звані ієрархічні імена, що включають DNS ім'я, зареєстроване за розробником.

Вимоги до процесу ініціалізації

Визначають переносиме оточення для ініціалізаційних скриптів застосунків, які автоматично запускаються при старті і завершенні роботи системи. Це оточення включає:

  • інтерфейс, за допомогою якого застосунки можуть переносимим чином реєструвати і видаляти скрипти ініціалізацій з системи;
  • визначення семантики рівнів виконання (run levels);
  • визначення ідентифікаторів стандартних пристроїв для використання при визначенні залежностей ініціалізаційних скриптів (наприклад: $local_fs, $network, $remote_fs);
  • набір переносимих функцій командного процесора для використання в ініціалізаційних скриптах.

Вимоги до користувачів і груп

Стандарт LSB вимагає визначити трьох обов'язкових користувачів і груп, які зобов'язані бути присутнім у всіх системах, і набір опціональних системних користувачів і груп.

Вимоги до інсталяції програмного забезпечення

Призначені для надання можливості реалізувати інсталяцію/деінсталяцію застосунків переносимим чином. Для досягнення цієї мети LSB визначає формат файлу, що містить дистрибутив застосунку як підмножину формату RPMv3 (Red Hat Package Manager), розробленого компанією Red Hat, Inc [RPM30]. При цьому LSB не вимагає використання утиліти rpm або підтримка бази даних RPM, що дозволяє реалізувати LSB-сумісну інсталяцію на основі альтернативних механізмів управління програмним забезпеченням. Крім того, LSB допускає можливість розповсюдження застосунків не тільки у вигляді пакетів RPM, але і в інших формах, за умови, що використовуваний інсталятор розповсюджується разом з застосунком і є LSB-сумісним застосунком.

LSB C++

Містить вимоги наступних видів:

  • представлення C++ даних;
  • правила перетворення ідентифікаторів;
  • бінарний інтерфейс базових бібліотек.

Вимоги до представлення C++ даних описують правила представлення C++ класів в пам'яті машини. Правила перетворення ідентифікаторів визначають, як має відбуватися перетворення ідентифікаторів мови програмування C++ в бінарні символи об'єктного коду. І нарешті, опис бінарного інтерфейсу базових бібліотек C++ містить вимоги до складу і функціональності бінарних символів з бібліотеки підтримки мови C++.

LSB Desktop

Визначає вимоги до бінарного інтерфейсу бібліотек, призначених для роботи застосунків, орієнтованих на взаємодію з користувачем. До числа цих бібліотек входять:

  • графічні бібліотеки (libX11, libSM, libICE, libXt, libXext, libXi);
  • бібліотеки OpenGL (libGL);
  • бібліотеки PNG (libpng12);
  • бібліотеки JPEG (libjpeg);
  • бібліотеки конфігурації шрифтів (libfontconfig);
  • бібліотеки сімейства GTK+ (libglib-2.0, libgobject-2.0, libgmodule-2.0, libatk-1.0, libpango-1.0, libpangoxft-1.0, libpangoft2-1.0, libgdk_pixbuf-2.0, libgdk_pixbuf_xlib-2.0, libgdk-x11-2.0, libgtk-x11-2.0);
  • бібліотека Qt3 (libqt-mt);
  • бібліотека XML2 (libxml2).

Всього в LSB 3.1 з перерахованих вище бібліотек стандартизовано 19103 бінарних символи. Також LSB Desktop входять 3 утиліти, призначеної для конфігурації шрифтів.

LSB Printing

Архітектурно-нейтральна частина стандарту. Містить Common Unix Printing System (CUPS), команди foomatic-rip і gs, які забезпечують сумісність майже з усіма спулерами (програмами-планувальниками), а також можливість виведення даних на PostScript PDF

Історія Linux Standard Base

Робота з розробки стандарту LSB стартувала на початку 1998 року, і вже в жовтні 1999 з'явився перший варіант стандарту LSB 0.1. Після серії попередніх версій 29 червня 2001 року була випущена перша офіційна версія стандарту - LSB 1.0. Ця версія складалася з єдиного документа, в якому були об'єднані вимоги частин LSB Core і невеликої підмножини LSB Desktop. Спочатку стандарт підтримував тільки одну архітектуру - IA32. Прикладний бінарний інтерфейс версії 1.0 складався з вимог до 15 бібліотек, в яких було стандартизовано 3040 функцій.

Версія 1.1 була випущена 22 січня 2002 року. Основні зміни торкнулися бібліотеки libc, в якій з'явилося 68 нових функцій. Велику частину з них склали функції підтримки RPC (Remote Procedure Call). Крім того, в бібліотеці libpthread були стандартизовані функції роботи з атрибутом pshared м'ютексів, в бібліотеці librt - функції роботи з таймерами, а в бібліотеці libm - функція clog. З графічних бібліотек навпаки було видалено 22 функції, 14 з яких знов з'явилися у версії LSB 1.2, опублікованій 28 червня 2002 року.

Найбільш важливою особливістю версії 1.2 стала підтримка другої архітектури (PPC32). Також в цій версії бінарний інтерфейс був розширений 6 новими функціями. На базі версії 1.2 FSG в серпні 2002 року оголосила про початок сертифікаційної програми.

У LSB 1.3, випущеній 17 грудня 2002 року, була реалізована підтримка широшого переліку архітектури (IA32, IA64, PPC32, S390, S390X) і була проведена реорганізація базових бібліотек. Бібліотеку librt видалили із стандарту, оскільки асинхронний ввод-вивод, що становить основну її частину, не повністю підтримувалося всіма дистрибутивами операційної системи Linux. Зате в стандарті з'явилися дві нові бібліотеки: libpam (модуль ідентифікації, що настроюється) і libgcc_s (незалежна від мови бібліотека підтримки компілятора gcc).

У LSB 2.0, опублікованому 31 серпня 2004 року, вперше був стандартизований бінарний інтерфейс бібліотеки підтримки мови C++: libstdc++. Іншою важливою зміною стало те, що до того монолітний текст стандарту був роздільний на три модулі: LSB Core, LSB C++ і LSB Graphics. Версія 2.1 від 11 березня 2005 року містила невеликі зміни, що торкнулися уточнення інтерфейсів libc, libm, libpthread і libz.

Наступна версія стандарту LSB 3.0 з'явилася 6 липня 2005 року. При її розробці почалася робота за погодженням стандарту LSB з вимогами стандарту IEEE Std 1003.1 (POSIX). Серед ключових змін слід зазначити перехід на новий бінарний інтерфейс C++, який був реалізований в компіляторі gcc 3.4.4, а також додавання нової бібліотеки libXi до складу модуля LSB Graphics і повернення в ряди LSB Core бібліотеки librt.

У складі бібліотеки librt повернулися не всі функції, а тільки функції роботи з годинником, таймерами і розподіленою пам'яттю. А функції асинхронного вводу-виводу як і раніше залишилися за бортом LSB 3.0.

LSB 3.1 публікувався частинами: LSB 3.1 Core з'явився 27 жовтня 2005 року, LSB 3.1 C++ і LSB 3.1 Desktop - 24 квітня 2006 року. Таке рішення було пов'язане з переговорами про присвоєння стандарту LSB Core статусу міжнародного стандарту ISO. Переговори на цю тему почалися ще під час роботи над LSB 2.0, а восени 2005 року цей процес успішно завершився і LSB 3.1 Core отримав статус міжнародного стандарту ISO/IEC 23360.

З технічної точки зору LSB 3.1 відрізняється в першу чергу істотним розширенням стандартизованих інтерфейсів, призначених для застосунків з графічним користувацьким інтерфейсом. Це розширення привело до перейменування модуля LSB Graphics в LSB Desktop. Поява опційного модуля LSB Qt 4 пов'язана з тим, що розробники стандарту підготували опис нової версії бібліотеки Qt, але оскільки ще не всі основні дистрибутиви Linux перейшли на цю версію, та вимога на наявність бібліотеки Qt 4 була зроблена необов'язковою.

Версія 3.2 була випущена 28 січня 2008 року. До розділів Core, Desctop та C++ додані

  • Друк: Включає Common Unix Printing System (CUPS) і нові команди foomatic-rip і gs, які забезпечують сумісність майже з усіма спулерами (програмами-планувальниками), а також можливість виведення даних на PostScript PDF.
  • Runtime languages: Включає Perl і Python. Будь-який застосунок, заснований на цих мовах, може розраховувати на доступність стандартного набору властивостей і бібліотек. Додаються два набори тестів, поодинці для кожної мови.

"Пробний стандарт" включає два розділи: звук і інтеграція робочих столів. Advanced Linux Sound Architecture (ALSA), яка включена в більшість сучасних дистрибутивів, є частиною стандарту. Включені команди xdg-utils з складу Portland Project, вони дозволяють з командного рядка встановлювати і видаляти теми різних меню на робочому столі, а також джерела ікон, управління типами файлів, відправку пошти через вибрану користувачем поштову програму, настройка охоронця екрану і багато що інше.

LSB 4.0 Beta

14 жовтня 2008 Linux Foundation анонсувала[2][3] версію LSB 4.0 Beta, підсилену засобами для розробників.

Бета-версія специфікації Linux Standard Base (LSB) 4.0 розширює можливості розробників за рахунок використання технології, що дозволяє погоджувати розбіжності в різних варіантах Linux. Версія 4.0 містить в собі засоби перевірки коректності скриптів застосунків і каркасів, а також комплект розробника (SDK), що підтримує різні версії. Комплект розробника дозволяє створювати застосунки відповідно до попередніх специфікацій LSB, не міняючи SDK.

Модель перевірки скриптів для оболонки в LSB 4.0 дозволяє виявити потенційні проблеми в скриптах, при цьому скрипт в одному варіанті операційної системи може безпечно виконуватися в іншому. SDK в бета-версії може створювати застосунки для специфікацій LSB 3.0, 3.1, 3.2 або 4.0. Пакет SDK пропонуватиметься незалежно від випуску нових специфікацій.

Для шифрування LSB 4.0 спирається на Mozilla Network Security Services (NSS) і Netscape Portable Runtime (NSPR). Це поєднання забезпечує підтримку Secure Sockets Layer (SSL). Linux Foundation відмовилася від використання в LSB бібліотеки OpenSSL, незважаючи на її популярність, побоюючись, що можуть виникнути проблеми із стандартизацією.

Позиції Linux Standard Base

Стандарт LSB знайшов підтримку в індустрії. Багато дистрибутивів пройшли сертифікацію на відповідність LSB. Серед них

Хоча є і такі дистрибутиви, які націлені на роботу на передньому краю досягнень в світі Linux і не збираються брати участь в комерційній діяльності. Тому вони не зацікавлені в сертифікації і підтримці LSB. Як приклад такого дистрибутива можна привести Fedora.

Користувачі і постачальники застосунків також взяли участь в розповсюдженні стандарту. Одним із способів участі стало те, що окремі гравці на ринку Linux і, зокрема, IBM включили сертифікацію на відповідність LSB як обов'язкову вимогу при укладенні контрактів з своїми партнерами. Істотну роль в підтримці стандарту також зіграли такі корпорації як Intel і HP.

В той же час не можна сказати, що розробники стандарту LSB не зазнавали проблем. Основне розчарування, пов'язане із стандартом, з'явилося наслідком завищених очікувань що сформувалися до його створення. Багато хто вважав, що з появою LSB можна буде один раз скомпілювати застосунок, і він працюватиме на всіх дистрибутивах Linux і інших LSB-сумісних операційних системах для даної апаратної платформи. На жаль, дійсність опинилася дещо складнішою. Незважаючи на постійне зростання LSB багатьом застосункам, як і раніше, не вистачає функціональності, описаної в стандарті, для реалізації всіх потреб переносимим чином. LSB розвивається в цьому напрямі, стандартизуючи все більше неохоплених раніше інтерфейсів між застосунками і операційною системою.

Ще одна проблема на шляху до досягнення працездатності цього принципу полягає у відсутності зворотної сумісності між основними версіями стандарту. Це означає, що застосунок має бути перекомпільований для кожної такій версії. Звичайно, основних версій стандарту значно менше, ніж різних дистрибутивів Linux, але все одно це порушення принципу, яке є одним з джерел обдурених очікувань. Причина відсутності зворотної сумісності полягає в постійній зміні бінарних інтерфейсів і проблематичності підтримки їх сумісності. На рівні двійкових кодів значно менше гнучкості в порівнянні з рівнем початкових кодів. Хоча підтримка версій бінарних символів в сукупності з іншими механізмами і дозволяє організувати зворотну сумісність, але це особливо складно зробити стандарту, якщо розробники його реалізацій не стурбовані проблемою зворотної сумісності.

Інша проблема стандарту LSB полягає в розриві між бінарним рівнем стандарту і початковим кодом застосунків. Розробники LSB надають разом із стандартом набір інструментів, призначених для полегшення розробки LSB-сумісних застосунків. Але функціональності інструментів і особливо документація з їхнього використанню не вистачає розробникам для того, щоб розробка LSB-сумісних застосунків стала простою і зрозумілою справою.

Виноски

  1. ↑ Project Proposal and Call for Participation: The Linux Standard Base (LSB) Project
  2. ↑ LSB Beta Reveals New Tools, Features for Developers
  3. ↑ Computerworld. Объединить Linux вокруг LSB

Посилання

Дивись також

Отримано з https://uk.wikipedia.org/w/index.php?title=Linux_Standard_Base&oldid=4365429