Linux Standard Base

Linux Standard Base

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. LSB забезпечує сумісність між застосунками і операційною системою Linux, що дозволяє розробникам застосунків охоплювати різні дистрибутиви Linux, підготувавши для них єдиний інсталяційний пакет. Відштовхуючись при оформленні програмних продуктів від вимог LSB, виробники ПЗ можуть уніфікувати процес розробки застосунків і уникають необхідності стежити за комплектацією різних дистрибутивів Linux, поточними версіями бібліотек і програмних модулів. LSB також дозволяє постачальникам різних дистрибутивів продемонструвати своїм клієнтам, що їхній дистрибутив відповідає загальному набору стандартів для галузі, і що вони разом працюють над просуванням Linux. LSB виконує важливу роль щодо запобігання фрагментації дистрибутивів Linux, незважаючи на різноманіття яких, базовий бінарний інтерфейс (ABI) дистрибутивів вдається стримувати в певному незмінному руслі.

Крім безпосередньо специфікацій на ABI-інтерфейс в LSB входить набір засобів для тестування і розробки застосунків і дистрибутивів:

• Linux App Checker - програма, що дозволяє розробникам тестувати їхні програми на предмет сумісності з LSB;
• LSB SDK — комплект засобів для розробки, що дозволяє створювати виконувані файли, сумісні з LSB;
• LSB Distribution Checker — засоби для перевірки сумісності дистрибутивів зі специфікаціями LSB.

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

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

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

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

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

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

Будь-який стандарт, що описує інтерфейси на рівні двійкового коду, залежить від архітектури апаратного забезпечення, на якій має працювати двійковий код. Водночас тільки невелика частина стандарту 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);
• бібліотека підтримки мови Сі (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 визначають необхідність наявності і правил функціонування 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

14 жовтня 2008 Linux Foundation анонсувала версію 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, незважаючи на її популярність, побоюючись, що можуть виникнути проблеми зі стандартизацією.

У грудні 2010 некомерційна організація Linux Foundation оголосила результати сертифікації Linux-дистрибутивів на предмет відповідності стандарту LSB 4.0, випущеному за два роки тому. Сумісність зі стандартом LSB 4.0 підтвердили всі провідні Linux-компаній та дистрибутиви, включаючи Canonical, Kylin, Linpus, Mandriva, Neoshine, Novell, Oracle, Debian, Red Flag Linux і Red Hat.

LSB 5.0

5 червня 2015 організація Linux Foundation опублікувала значні версії основоположних для Linux-систем стандартів LSB 5.0 (Linux Standard Base) і FHS 3.0 (Filesystem Hierarchy Standard).

Основні зміни в Linux Standard Base 5.0:

• Припинено підтримка бібліотеки Qt 3, що дозволяє дистрибутивам не включати цю застарілу гілку Qt для збереження сумісності з LSB. Застосунки на базі Qt3 не є сумісними зі стандартом LSB 5, крім випадку використання статичного зв'язування з бібліотекою.
• Удосконалена модульна організація LSB, специфікації тепер не просто логічно розділені по області призначення, а й самодостатні, тобто кожна з частин LSB може застосовуватися відокремлено, даючи можливість враховувати у застосунку тільки необхідні частини стандарту, без залежності від повного набору специфікацій. У LSB 5.0 доступно п'ять модулів LSB Core, LSB Desktop, LSB Languages, LSB Imaging і LSB Trial Use (GTK3+ і libpng). Основною обов'язковою залежністю є тільки модуль LSB Core, інші модулі можна використовувати відокремлено. Модуль LSB Trial Use є опцією і не обов'язковий до реалізації.
• Підвищено мінімальні вимоги до базових бібліотек: GTK+ 2.32 (для сумісності з LSB Trial Use — GTK+/GDK 3.0), Cairo 1.30, OpenGL 2.1;
• Додана підтримка XCB API для X11;
• Включені нові бібліотеки SANE, libncursesw, libtiff і libxslt;
• Додані нові програмні інтерфейси, включаючи aio, argz *, envz *, CUPS ippReadIO/ippWriteIO і inflateCopy (libz).

Позиції Linux Standard Base

Стандарт 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-сумісних сторонніх застосунків. На думку деяких розробників, на забезпечення сумісності з LSB витрачається занадто багато сил, при неочевидній користі від такої сумісності.

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

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

Див. також

• POSIX
• Filesystem Hierarchy Standard
• glibc

Посилання

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