Linux Standard Base

Із самого початку операційна система 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.

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

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

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

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

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

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

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

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

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

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

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

Робота з розробки стандарту 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 знайшов підтримку в індустрії. Багато дистрибутивів пройшли сертифікацію на відповідність LSB. Серед них

• Asianux (Server 3.0),
• Debian (Etch),
• Mandriva (2007),
• Novell (SUSE Linux Enterprise 10),
• openSUSE 10.2
• Red Hat (Enterprise Linux 5),
• Ubuntu (Dapper),
• Xandros (Server 1.0)
• Mandrakelinux Corporate Server
• SGI ProPack for Linux3

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

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

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

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

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

Влітку розробники Debian поставили під сумнів доцільність забезпечення підтримки в дистрибутиві стандарту Linux Standard Base, який визначає сервіси, засоби розробки, бінарні інтерфейси та бібліотеки, що дають можливість виконання в дистрибутиві LSB-сумісних сторонніх застосунків.[6] На думку деяких розробників, на забезпечення сумісності з LSB витрачається занадто багато сил, при неочевидній користі від такої сумісності.

Підтримуваний в Debian стандарт LSB 4.1 описує 1493 компонентів, 1672 бібліотек, 38491 команд, 30176 класів і 716 202 інтерфейсів. При тому, що на час розгляду на предмет сумісності з LSB сертифіковане всього 8 застосунків, з яких тільки одна програма сертифікована на відповідність LSB 4.0+. Інакше кажучи, вся величезна робота і ті рамки, в які доводиться укладатися заради сумісності з LSB, робляться заради кількох власницьких програм, розробники яких не бажають сформувати специфічні для дистрибутиву пакунки.

Головною ж проблемою є те, що ніхто з розробників Debian не зацікавлений у супроводі пакунків з компонентами для підтримки LSB. З моменту пропозиції про припинення підтримки LSB минуло три місяці, за які не знайшлося бажаючих взяти на себе роботу з підтримки пакетів, пов'язаних з LSB. У зв'язку з цим восени 2015 вирішено[7] зберегти тільки пакети lsb-base і lsb-release з невеликим набором shell-функцій для скриптів ініціалізації та утилітою для виводу рівня сумісності з LSB, відкинувши все інше.

• POSIX
• Filesystem Hierarchy Standard
• glibc

• Офіційний сайт(англ.)
• Linux Standard Base wiki(англ.)
• А. В. Хорошилов. Linux Standard Base: история успеха?(рос.)
• Д. В. Силаков, Труды Института системного программирования РАН. Текущее состояние и перспективы развития инфраструктуры LSB