Соответствует ли astra linux стандарту lsb linux standard base

Обновлено: 04.07.2024

Astra Linux придерживается стандарта Filesystem Hierarchy Standard для каталогов и имён файлов. Этот стандарт позволяет пользователям и программному обеспечению быть уверенным в расположении файлов и каталогов. Уровень корневого каталога представляется просто косой чертой «/» и содержат следующие каталоги:

Каталог Содержит
bin необходимые исполняемые файлы
boot статичные файлы системного загрузчика
dev файлы устройств
etc настройки системы данной машины
home домашние каталоги пользователей
lib необходимые библиотеки общего пользования и модули ядра
lost+found потерянные файлы
media точки монтирования для съёмных носителей
mnt точка монтирования для временно монтируемой файловой системы
opt дополнительные пакеты программного обеспечения
proc виртуальный каталог для системной информации
root домашний каталог суперпользователя
run изменяемые данные времени выполнения
sbin необходимые системные исполняемые файлы
srv данные сервисов, предоставляемых системой
sys виртуальный каталог для системной информации
tmp временные файлы
usr подкаталоги многих программ (вторичная иерархия)
var изменяемые данные

Дисковое пространство может использоваться совершенно по разному, в зависимости от настроек системы и специфики решаемых задач. Приводимые здесь рекомендации являются лишь отправной точкой в решении задачи разметки и важных предположений относительно каталогов и разделов:

Astra Linux распознаёт следующие файловые системы:

Система Описание
Ext4 журналируемая файловая система, в которой представлен механизм записи файлов в непрерывные участки блоков, уменьшающий фрагментацию и повышающий производительность. Эта файловая система используется по умолчанию при автоматическом разбиении диска инсталлятором.
Ext3 журналируемая файловая система, в которой предусмотрена запись некоторых данных, позволяющих восстановить файловую систему при сбоях в работе компьютера.
Ext2 файловая система, достаточно быстра для того, чтобы служить эталоном в тестах производительности файловых систем. Она не является журналируемой файловой системой и это её главный недостаток.
BTRFS универсальная файловая система, основанная на структурах B-деревьев и работающая по принципу «копирование при записи» (copy-on-write).
JFS 64-битная журналируемая файловая система, созданная IBM.
XFS высокопроизводительная 64-битная журналируемая файловая система, отличается от других файловых систем тем, что она изначально была рассчитана для использования на дисках большого объёма.
Fat16 файловая система, сейчас широко используемая в картах памяти фотоаппаратов и других устройств.
Fat32 файловая система основанная на Fat16. Cоздана, чтобы преодолеть ограничения на размер тома в Fat16
SWAP раздел жёсткого диска, предназначенная для виртуальной памяти (раздел подкачки).
NTFS файловая система для семейства операционных систем Microsoft Windows.
HSF (HSF+) файловая система, разработанная Apple Inc.

Так же при установке Astra Linux вы можете увидеть при выборе файловой системы, следующие физические тома:

  • Физический том для защитного преобразования. При установке данного раздела, на нем будут размещены каталоги /var и /home. Выбор для защиты именно этих каталогов обусловлен тем, что в них обычно находятся конфиденциальные данные (базы данных в каталоге /var и пользовательские данные в каталоге /home).
  • Физический том для raid. Данный раздел служит для создания программного raid.
  • Физический том для LVM. Данный раздел служит для создания дополнительного слоя абстракции железа, позволяющего собрать множества разнородных дисков в один, и затем снова разбить этот один именно так как нам хочется.

Ручная разметка диска.

Для выполнения ручной разметки надо знать, что разметка диска заключается в выделении области для установки новой системы, какие разделы будут использоваться для установки. Далее рассмотрим пример из 4 разделов: загрузочный, корневой, файл подкачки и домашний.

Выбираем "Вручную" и нажимаем "Продолжить".


Выбираем диск, который будем размечать и нажимаем "Продолжить".


Создаём новую пустую таблицу разделов, выбрав "Да" и нажав "Продолжить". Данные действия полностью сотрут данные на ранее используемом диске.


Создадим первый раздел для загрузчика. Выбираем "СВОБОДНОЕ МЕСТО" и нажимаем "Продолжить".


Выбираем "Создать новый раздел" и нажимаем "Продолжить".


Выделим под загрузчик 100 MB и нажимаем "Продолжить".


Выбираем тип раздела "Первичный" и нажимаем "Продолжить".


Устанавливаем позицию нового раздела в "Начало" диска и нажимаем "Продолжить".


Выбираем "Использовать как:" и нажимаем "Продолжить".


В зависимости от загрузчика выбираем: для MBR - "Файловая система Ext2" или для UEFI GPT - "Системный раздел EFI".

GPT и MBR – эти стили разделов жёсткого диска, их также называют стили разметки или таблицы разделов диска. В современных системах используется GPT. Если у вас нет в списке для выбора "Системный раздел EFI" выбирайте "Файловая система Ext2".


Выбираем "Настройка раздела закончена".


Если же вы выбрали "Файловая система Ext2" выбираем "Точка монтирования" и нажимаем "Продолжить".


Указываем, что этот раздел будет загрузчиком, выбрав "/boot -- статические файлы системного загрузчика" и нажимаем "Продолжить".


Для назначении метки разделу выбираем "Метка" и нажимаем "Продолжить".


Назначаем метку для загрузчика "boot" и нажимаем "Продолжить".


Выбираем "Зарезервированные блоки" и нажимаем "Продолжить".


Устанавливаем значение "0%" и нажимаем "Продолжить".


Сделаем раздел загрузочным, выбрав "Метка 'загрузочный':" и нажав "Продолжить".


После чего выберем "Настройка раздела закончена" и нажимаем "Продолжить".

Если Метка 'загрузочный' не переходит в "вкл" как показано ниже, то необходимо выбрать "Использовать как: системный раздел EFI".


Раздел для загрузчика размечен. Далее делаем по аналогии корневой раздел:

  • Выбираем "СВОБОДНОЕ МЕСТО" (при выборе системного раздела EFI остаётся свободное место 1 MB перед ним, его не выбирать).
  • "Создать новый раздел".
  • Выделяем под корневой каталог 20 GB.
  • Указываем "Логический".
  • Устанавливаем позицию нового раздела в "Начало" диска.
  • Проверяем, что настройки раздела указаны как представлено ниже. Выбираем "Настройка раздела закончена" и нажимаем "Продолжить".


Корневой раздел размечен.

Размер файла подкачки зависит от количество оперативной памяти. Если оперативной памяти менее 3 GB, то необходимо выделать двукратное количество, то есть при 1 GB оперативной памяти выделяется 2 GB. До 16 GB оперативной памяти необходимо выделять равное количество, то есть при 8 GB оперативной памяти выделяется 8GB. При объеме оперативной памяти выше 16 GB и при не использовании режима Hibernate (Гибернация - спящий режим), необходимо выделить символический размер 2 GB или более, в зависимости от используемого программного обеспечения, которому требуется большое количество оперативной памяти (пример: обработка большого количество слоёв в графическом редакторе GIMP).

Далее делаем по аналогии файл подкачки:

  • Выбираем "СВОБОДНОЕ МЕСТО".
  • "Создать новый раздел".
  • Выделяем память под файл подкачки согласно рекомендациям выше. В примере используется 4 GB оперативной памяти, значит выделим под файл подкачки 4 GB.
  • Указываем "Логический".
  • Устанавливаем позицию нового раздела в "Начало" диска.
  • Выбираем "Использовать как:".
  • Выбираем "раздел подкачки".
  • Выбираем "Настройка раздела закончена" и нажимаем "Продолжить".


Раздел файла подкачки размечен.

Далее делаем по аналогии раздел home:

Выбираем "СВОБОДНОЕ МЕСТО".

  • "Создаём новый раздел".
  • Оставляем максимальный размер раздела.
  • Указываем "Логический".
  • Выбираем "Точка монтирования".
  • Указываем, что этот раздел будет загрузчиком, выбрав "/home -- домашние каталоги пользователей".
  • Для назначении метки разделу выбираем "Метка".
  • Назначаем метку для раздела "home".
  • Выбираем "Зарезервированные блоки".
  • Устанавливаем значение "0%".
  • После чего выберем "Настройка раздела закончена" и нажимаем "Продолжить".


В итоге получится 4 раздела: загрузочный, корневой, файл подкачки и домашний. Выбираем "Закончить разметку и записать изменения на диск" и нажимаем "Продолжить".

Для "Системный раздел EFI" получим следующее:


Для "Файловой системы Ext2" получим следующее:


Подтверждаем изменения, выбрав "Да" и нажав "Продолжить". Ручная разметка закончена, далее продолжаем установку как обычно.

Astra Linux можно разделить на большее количество разделов: корневой (/), загрузочный (/boot), домашний (/home), временный (/tmp), статичный (/usr), изменяемый (/var), служебный (/srv), дополнительный (/opt), локальный (/usr/local) и иные.

Также можно монтировать разделы с параметрами, выбрав при создании раздела "Параметры монтирования:" и нажать "Продолжить".


Выбрав необходимые параметры, нажать "Продолжить".


К примеру для максимальной защиты Astra Linux, которая будет использоваться в качестве сервера, рекомендуется разбить диск на разделы, с определенными параметрами, а именно:

Если у Вас FreeBSD/Solaris/AIX -- см. "Руководство администратора безопасности. FreeBSD/Solaris/AIX".

Публикация: 20 Декабрь 2010 - 18:03, редакция: 01.02.2011 16:01

Для просмотра информации о лицензии выполните:

Для ввода лицензии выполните:

Серийный номер следует вводить с соблюдением регистра символов.
Утилита cpconfig находится в /opt/cprocsp/sbin/<архитектура> .

Попробуйте сначала поставть пакеты совместимости с LSB 3.0 или 3.1 из состава Вашего дистрибутива (названия могут несколько варьироваться, обычно lsb-3.0, lsb-3.1, lsb-base, lsb-core), а затем установить CSP.

ВНИМАНИЕ: установка CSP на неподдерживаемую ОС не будет являться сертифицированным решением и не поддерживается.

Публикация: 20 Декабрь 2010 - 17:57, редакция: 20.12.2010 17:57

Сначала необходимо установить пакет LSB из состава дистрибутива:

apt-get install lsb-3.0

Затем пакет совместимости, поставляющийся вместе с CSP:

rpm -i ./cprocsp-compat-altlinux-1.0.0-1.noarch.rpm

После этого можно устанавливать необходимые пакеты из состава CSP. Установка осуществляется при помощи утилиты rpm.

Сначала необходимо поставить(если не установлены) пакеты LSB из состава дистрибутива, а также пакет alien, который является штатным средством для установки .rpm:

apt-get install lsb-base alien lsb-core

Затем при помощи alien поставить необходимые пакеты CSP, например:

alien -kci ./lsb-cprocsp-base-3.6.4-4.noarch.rpm
alien -kci ./lsb-cprocsp-rdr-3.6.4-4.i486.rpm
alien -kci ./lsb-cprocsp-kc1-3.6.4-4.i486.rpm
alien -kci ./lsb-cprocsp-capilite-3.6.4-4.i486.rpm

Публикация: 20 Декабрь 2010 - 17:26, редакция: 07.12.2011 15:52

Нет, дистрибутив поставляется только в .rpm. Все ОС семейства Linux, для работы под управлением которых сертифицирован продукт либо основаны на rpm, либо соответствуют LSB, либо планируются к сертификации по стандарту LSB 3.1. Обязательным требованием для соответствия LSB является наличие в ОС механизма для установки rpm, следовательно, если используемая Вами ОС входит в число поддерживаемых операционных систем, в ней есть механизм для установки .rpm. Для debian, ubuntu и основанных на них дистрибутивах это утилита alien.

Публикация: 20 Декабрь 2010 - 17:25, редакция: 20.12.2010 17:28

По сотстоянию на момент сертификации в этот список входили:

Программно-аппаратные среды, удовлетворяющие стандарту LSB 3.1:
- Asianux Server 3 (ia32, x86-64)
- Bharat Operating System Solutions (BOSS) Linux 1.0 (ia32)
- Bharat Operating System Solutions (BOSS) Linux 2.0 (ia32)
- Booyo 2.5 (ia32, x64)
- Linpus Linux 9.4 (ia32)
- Linpus Linux 9.5 (ia32, x64)
- Mandriva Linux 2007.0 (ia32)
- Mandriva Linux Corporate Desktop 4.0 (ia32)
- Mandriva Linux Corporate Server 4.0 (ia32)

Публикация: 20 Декабрь 2010 - 17:12, редакция: 20.12.2010 17:28

КриптоПро CSP версии 3.0 работает под управлением операционных систем:
- Red Hat Linux 7, 9 (платформа ia32)
- FreeBSD 5 (платформа ia32)
- Solaris 9 Update 4 (платформы sparc, ia32).

КриптоПро CSP версии 3.6 работает под управлением операционных систем:
- FreeBSD 7/8 (платформа ia32)
- Solaris 9/10 (платформы sparc, ia32, x64)
- AIX 5/6 (платформа Power PC)
- ALT Linux Server (платформы ia32, x64)
- Debian (платформы ia32, х64)
- Trustverse Linux XP (платформа ia32)
- SPLAT (платформы ia32, х64)

Standard Base Linux ( LSB ) был совместный проект нескольких дистрибутивов Linux под организационной структурой Linux Foundation , стандартизировать структуру системы программного обеспечения, в том числе Filesystem Hierarchy Standard используется в ядре Linux . LSB был основан на спецификации POSIX , Single UNIX Specification (SUS) и нескольких других открытых стандартах, но расширил их в определенных областях.

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

Соответствие LSB может быть сертифицировано для продукта с помощью процедуры сертификации.

LSB определяет стандартные библиотеки (сосредоточенные вокруг ld-lsb.so ), ряд команд и утилит, расширяющих стандарт POSIX , структуру иерархии файловой системы , уровни выполнения , систему печати, включая спулеры, такие как CUPS, и инструменты, такие как Foomatic , и несколько расширений. в систему X Window . В нем также указаны средства загрузки, такие как $ local_fs , $ network , которые использовались для указания зависимостей служб в сценариях инициализации в стиле System V. Машиночитаемый блок комментариев в верхней части сценария предоставляет информацию, необходимую для определения, в какой момент процесса инициализации сценарий должен быть вызван; это называлось заголовком LSB.

Эта команда lsb_release -a была доступна во многих системах для получения сведений о версии LSB или могла быть доступна путем установки соответствующего пакета, например redhat-lsb пакета в дистрибутивах с добавлением Red-Hat, таких как Fedora , или lsb-release пакета в дистрибутивах на основе Debian.

Стандарт перестал обновляться в 2015 году, и текущие дистрибутивы Linux не придерживаются его и не предлагают его, однако команда lsb_release все еще доступна.


СОДЕРЖАНИЕ

Обратная совместимость

LSB стремится сделать двоичные файлы пользовательского пространства переносимыми

LSB был разработан для обеспечения двоичной совместимости и создал стабильный двоичный интерфейс приложений (ABI) для независимых поставщиков программного обеспечения . Для обеспечения обратной совместимости каждая последующая версия была чисто аддитивной. Другими словами, интерфейсы только добавились; никакие интерфейсы не были удалены. LSB принял политику устаревания интерфейса, чтобы дать разработчикам приложений достаточно времени на случай, если интерфейс был удален из LSB.

Это позволяло разработчику полагаться на каждый интерфейс в LSB в течение известного времени, а также планировать изменения. Интерфейсы были удалены только после того, как они были помечены как «устаревшие» по крайней мере для трех основных версий, или примерно через одиннадцать лет.

LSB 5.0 был первым крупным выпуском, в котором была нарушена обратная совместимость с более ранними версиями.

История версий

  • 1.0: первый выпуск от 29 июня 2001 г.
  • 1.1: Выпущено 22 января 2002 г. Добавлены аппаратные спецификации ( IA-32 ).
  • 1.2: Выпущено 28 июня 2002 г. Добавлены аппаратные спецификации ( 32-разряднаяверсия PowerPC ). Сертификация началась в июле 2002 года.
  • 1.2.1: Выпущено в октябре 2002 г. Добавлен Itanium .
  • 1.3: выпущена 17 декабря 2002 г. Добавлены аппаратные спецификации (Itanium, Enterprise System Architecture / 390, z / Architecture).
  • 2.0: выпущена 31 августа 2004 г.
    • LSB модульный для LSB-Core, LSB-CXX, LSB-Graphics и LSB- I18n (не выпущен)
    • Новые аппаратные спецификации ( 64-разряднаяверсия PowerPC , AMD64 )
    • Синхронизирован с единой спецификацией UNIX (SUS) версии 3
    • Библиотека GNU C версии 2.3.4
    • C ++ ABI заменен на тот, который используется в gcc 3.4.
    • Основная спецификация обновлена ​​до ISO POSIX (2003).
    • Технические исправления 1: 2005
    • Библиотека GNU C версии 2.4
    • Двоичная совместимость с LSB 3.x
    • Легче использовать SDK
    • Поддержка новых версий графических библиотек GTK и Cairo.
    • Java (дополнительный модуль)
    • Более простые способы создания пакетов RPM, совместимых с LSB
    • Crypto API (через библиотеку Network Security Services ) (дополнительный модуль)
    • Java удалена
    • Модули «Пробного использования» из LSB 4.0, охватывающие мультимедиа ( ALSA ), безопасность (NSS) и прочее для настольных компьютеров ( xdg-utils ), были продвинуты как требуемые подмодули.
    • Обновлены библиотеки GTK + , Cairo и CUPS.
    • Добавлены три новых набора тестов
    • Библиотека GNU C версии 2.10 (для psiginfo)
    • Первый основной выпуск, который нарушает обратную совместимость с более ранними версиями (совместим с LSB 3.0 и в основном совместим с LSB 3.1 и более поздними версиями, за некоторыми исключениями)
    • Включает изменения, внесенные в FHS 3.0.
    • Библиотека Qt 3 удалена
    • Развитая модульная стратегия; LSB разделен на модули LSB Core, LSB Desktop, LSB Languages, LSB Imaging и LSB Trial Use

    Стандарт ISO

    • ISO / IEC 23360-1: 2006 Базовая спецификация ядра Linux Standard Base (LSB) 3.1 - Часть 1: Общая спецификация
    • ИСО / МЭК 23360-2: 2006 Базовая спецификация ядра Linux Standard Base (LSB) 3.1 - Часть 2: Спецификация архитектуры IA-32
    • ИСО / МЭК 23360-3: 2006 Стандарт ядра Linux Standard Base (LSB), спецификация 3.1 - Часть 3: Спецификация для архитектуры IA-64
    • ISO / IEC 23360-4: 2006 Стандарт ядра Linux Standard Base (LSB), спецификация 3.1 - Часть 4: Спецификация для архитектуры AMD64
    • ИСО / МЭК 23360-5: 2006 Стандарт ядра Linux Standard Base (LSB), спецификация 3.1 - Часть 5: Спецификация архитектуры PPC32
    • ИСО / МЭК 23360-6: 2006 Базовая спецификация ядра Linux Standard Base (LSB) 3.1 - Часть 6: Спецификация архитектуры PPC64
    • ISO / IEC 23360-7: 2006 Базовая спецификация ядра Linux Standard Base (LSB) 3.1 - Часть 7: Спецификация для архитектуры S390
    • ИСО / МЭК 23360-8: 2006 Базовая спецификация ядра Linux Standard Base (LSB) 3.1 - Часть 8: Спецификация для архитектуры S390X

    Также существует ISO / IEC TR 24715: 2006, который определяет области конфликта между ISO / IEC 23360 (спецификация Linux Standard Base 3.1) и международным стандартом ISO / IEC 9945: 2003 (POSIX).

    ISO / IEC 23360 и ISO / IEC TR 24715 можно бесплатно загрузить с веб-сайта ISO.

    Прием

    Хотя LSB был стандартом и не имел конкурентов, за ним последовали лишь несколько дистрибутивов Linux . Например, только 21 выпуск (версия) дистрибутива был сертифицирован для LSB версии 4.0, в частности Red Flag Linux Desktop 6.0, Red Hat Enterprise Linux 6.0, SUSE Linux Enterprise 11 и Ubuntu 9.04 (Jaunty Jackalope) ; еще меньше было сертифицировано для версии 4.1.

    LSB критиковали за то, что он не принимал участие в проектах, в первую очередь проекта Debian , за пределами сферы своих компаний-членов.

    Выбор формата пакета RPM

    В LSB указано, что программные пакеты должны поставляться либо как LSB-совместимая программа установки, либо (предпочтительно) поставляться в ограниченной форме в формате диспетчера пакетов RPM .

    Такой выбор формата пакета исключил использование многих других существующих форматов пакетов, несовместимых с RPM. Чтобы решить эту проблему, стандарт не диктовал, какой формат пакета система должна использовать для своих собственных пакетов, а просто то, что RPM должен поддерживаться, чтобы разрешить установку пакетов от сторонних дистрибьюторов в соответствующей системе.

    Ограничения Debian

    Debian включил необязательную поддержку LSB на раннем этапе, в версии 1.1 в «woody» (3.0; 19 июля 2002 г.), 2.0 в «sarge» (3.1; 6 июня 2005 г.), 3.1 в «etch» ​​(4.0; 8 апреля 2002 г.) 2007), 3,2 для lenny (5,0; 14 февраля 2009 г.) и 4,1 для «wheezy» (7; 4 мая 2013 г.). Чтобы использовать иностранные LSB-совместимые пакеты RPM, конечный пользователь должен использовать программу Debian Alien, чтобы преобразовать их в собственный формат пакетов, а затем установить их.

    Формат RPM, заданный LSB, имел ограниченное подмножество функций RPM - чтобы заблокировать использование функций RPM, которые нельзя было бы перевести в .deb с помощью Alien или других программ преобразования пакетов, и наоборот, поскольку каждый формат имеет возможности, которых нет у другого. На практике не все двоичные пакеты Linux обязательно были LSB-совместимыми, поэтому, хотя большинство из них можно было преобразовать между .rpm и .deb, эта операция была ограничена подмножеством пакетов.

    Используя Alien, Debian был LSB-совместимым для всех намерений и целей, но, согласно описанию их пакета lsb , наличие пакета «не означает, что мы считаем, что Debian полностью соответствует Стандартной базе Linux, и не должен быть истолковано как утверждение, что Debian совместим с LSB ".

    Debian стремился соответствовать LSB, но с множеством ограничений. Однако эти усилия прекратились примерно в июле 2015 года из-за отсутствия интереса и рабочей силы внутри проекта. В сентябре 2015 года проект Debian подтвердил, что, хотя поддержка стандарта иерархии файловой системы (FHS) будет продолжена, поддержка LSB прекращена. Ubuntu последовала за Debian в ноябре 2015 года.

    Качество комплектов тестов на соответствие

    Кроме того, комплекты тестов на соответствие критиковались за то, что они содержат ошибки и являются неполными - в частности, в 2005 году Ульрих Дреппер раскритиковал LSB за плохо написанные тесты, которые могут вызвать несовместимость между LSB-сертифицированными дистрибутивами, когда некоторые из них реализуют некорректное поведение, чтобы заставить ошибочные тесты работать, в то время как другие подать заявку и получить отказ от прохождения тестов. Он также осудил отсутствие тестирования приложений, указав, что тестирование только дистрибутивов никогда не может решить проблему приложений, полагающихся на поведение, определяемое реализацией.

    Для поставщиков, рассматривающих LSB-сертификаты в своих усилиях по переносимости, Linux Foundation спонсировал инструмент, который проанализировал и предоставил рекомендации по символам и библиотекам, выходящим за рамки LSB.

    ОС Linux появилась сначала только как ядро системы. К сожалению, ядро само по себе не очень полезно; программам нужна регистрация, управление файлами, компиляция новых программ и т.д. Для того чтобы сделать систему полезной, в рамках проекта GNU были добавлены разные средства. Они представляли собой клоны похожих программ, имевшихся в UNIX и UNIX-подобных системах того времени. Превращение системы Linux в подобие UNIX-системы установило первые стандарты для Linux, предоставляя программистам на языке С знакомую рабочую среду.

    Разные разработчики ОС UNIX (а позднее Linux) вставляли собственные расширения в команды и утилиты, которые включали в состав системы, и структура используемых ими файловых систем тоже слегка отличалась. Все это затрудняло создание приложений, способных выполняться в разных системах. Более того, программист не мог даже полагаться на то, что функциональные возможности системы были реализованы одинаково, или файлы конфигурации хранились в одном и том же месте.

    Стало ясно, что для сохранения подобия UNIX-систем нужна стандартизация, и такая работа сейчас ведется.

    Со временем не только стандарты двигались вперед, но и ОС Linux с впечатляющей скоростью совершенствовалась сообществом, поддержанным коммерческими организациями, такими как Red Hat и Canonical, и даже разработчиками не-Linux, например, корпорацией IBM. По мере развития Linux наряду с разработкой коллекции компиляторов gcc не только следила за соответствующими стандартами, но и определяла новые стандарты, если существующие оказывались неэффективными. В действительности по мере того, как ОС Linux и связанные с нею программные средства и утилиты становились все более популярными, разработчики UNIX-систем начали вносить изменения в свои продукты, чтобы сделать их более совместимыми с ОС Linux.

    В этой заключительной главе мы собираемся рассмотреть стандарты Linux, обращая внимание нате области, о которых вы должны знать для того, чтобы не только писать приложения, работающие в ваших системах Linux после их обновления, но и создавать программный код, который можно будет переносить в другие дистрибутивы Linux, а может быть и в UNIX-подобные системы, обеспечивая, таким образом, совместное использование ваших программ.

    В особенности мы коснемся следующих тем:

    Мы не собираемся подробно рассматривать содержание стандартов, многие из которых по объему сравнимы с данной книгой. Мы хотим обратить ваше внимание на ключевые стандарты, о которых следует знать, дать вам краткие исторические сведения о том, как развивались эти стандарты, и помочь решить, какие из них могут оказаться полезными при написании ваших собственных программ.

    Язык программирования С — de facto язык программирования ОС Linux, поэтому, для того чтобы писать программы на С для Linux, необходимо немного разобраться в его истоках, узнать, как менялся язык, и, что особенно важно понять, как проверяются программы на соответствие стандартам.

    Тем, кто не слишком любит историю, не стоит беспокоиться: эта книга о программировании, а не об истории, поэтому обзор будет очень кратким.

    Язык программирования С появился в начале 1970-х годов и был основан отчасти на более раннем языке программирования BCPL и расширениях для языка В. Деннис Ритчи (Dennis М. Ritchie) написал руководство пользователя для языка в 1974 г., и примерно в это же время С был использован как язык программирования для переработки ядра UNIX на компьютерах PDP-11. В 1978 г. Брайан Керниган (Brian W. Kernighan) и Ритчи написали классическое руководство по, языку "The С Programming Language" ("Язык программирования С").

    Очень быстро язык приобрел большую популярность, обусловленную, несомненно, отчасти быстрым ростом популярности UNlX-систем, но также и своими возможностями и понятным синтаксисом. Синтаксис языка С продолжал развиваться согласованно, но по мере того, как он изменялся все больше и больше по сравнению с первоначальным описанием, приведенным в книге, становилось ясно, что нужен стандарт, который соответствовал бы современному употреблению и был более строгим.

    В 1983 г. ANSI (American National Standards Institute, Американский институт стандартов) основал комитет стандартов X3J11 для разработки четкого и строгого определения языка. Попутно обе организации вносили в язык незначительные изменения, в особенности придавая ему долгожданную способность объявлять типы параметров, но в основном комитет просто вносил ясность и логическое обоснование существующего определения того, что составляло общеупотребительный вариант языка. Окончательный стандарт был опубликован в 1989 г. как ANSI Standard Programming Language С, X3.159-1989 или более кратко C89, иногда именуемый C90. (Этот последний превратился в стандарт ISO/IEC 9899:1990, Programming Languages — С. Оба стандарта формально идентичны.)

    Как и для большинства стандартов, публикация не закончила работу комитета, который продолжал устранять некоторые неточности, обнаруженные в спецификации, и в 1993 г. начал работу над новой версией стандарта, названного C9X. Комитет также публиковал, незначительные корректировки и обновления существующего стандарта в 1994-1996 гг.

    После разработки редактора Emacs (да, мы любим Emacs) следующим важным достижением проекта GNU, как упоминалось в главе 1, стал полностью бесплатный компилятор С, gcc, первая официальная версия которого была выпущена в 1987 г.

    Первоначально имя gcc расшифровывалось как GNU С Compiler (компилятор С проекта GNU), но, поскольку базовая рабочая среда компилятора теперь поддерживает много других языков программирования, таких как С++, Objective-C, FORTRAN, Java и Ada, а также библиотеки для этих языков, определение было заменено на более подходящее GNU Compiler Collection (коллекция компиляторов GNU).

    Компилятор С GNU всегда хорошо отслеживал развитие стандарта языка С, хотя он допускает некоторые расширения языка, и, безусловно, существуют незначительные задержки, как почти у всех компиляторов, между выходом стандарта и появлением версий компиляторов, точно следующих этой спецификации. Порой происходит обратное, и gcc предвосхищает слабые изменения стандарта, что тоже может совершенно сбивать с толку. У gcc есть ряд опций командной строки и других, позволяющих задать версию стандарта языка С, которой должен соответствовать компилятор, а также ряд других опций для управления степенью придирчивости или строгости компилятора.

    Теперь, когда вы узнали кое-что о стандарте С, давайте рассмотрим опции, которые предлагает компилятор gcc для гарантии соответствия стандарту языка С, на котором вы пишете. Есть три способа, позволяющих убедиться в том, что ваш код на С соответствует стандартам и не содержит изъянов: опции, контролирующие версию стандарта, соответствия с которой вы намерены добиваться, определения, контролирующие заголовочные файлы, и опции предупреждений, инициирующие более строгую проверку программного кода.

    У gcc есть огромный набор опций, и здесь мы рассмотрим лишь те из них, которые считаем наиболее важными. Полный перечень опций можно найти на страницах интерактивного справочного руководства gcc. Мы также кратко обсудим некоторые опции директивы

    которые можно применять; обычно их следует задавать в вашем исходном программном коде перед любыми строками с директивой или определять в командной строке gcc. Вас может удивить такое обилие опций для выбора применяемого стандарта вместо простого флага, заставляющего использовать современный стандарт. Причина заключается в том, что много более старых программ полагается на исторически сложившееся поведение компилятора и потребовалась бы значительная работа по их обновлению в соответствии с последними стандартами. Редко, если вообще когда-нибудь, вам захочется обновить компилятор для того, чтобы он начал прерывать работающий программный код. По мере изменения стандартов важно иметь возможность работать вопреки определенному стандарту, даже если это и не самая свежая версия стандарта.

    Даже если вы пишете маленькую программу для личного применения, когда соответствие стандартам, возможно, не так уж важно, часто имеет смысл включить дополнительные предупреждения gcc, чтобы заставить компилятор искать ошибки в вашем коде еще до выполнения программы. Это всегда эффективнее, чем выполнять по шагам код в отладчике и недоумевать по поводу возможного места возникшей проблемы. У компилятора есть много опций, которые не ограничиваются простой проверкой на соответствие стандартам, таких, как способность обнаруживать код, который удовлетворяет стандарту, но, возможно, имеет сомнительную семантику. Например, в программе может быть такой порядок выполнения, который позволяет обращаться к переменной до ее инициализации.

    Опции компилятора для отслеживания стандартов

    Приведенные далее опции передаются gcc в командной строке; мы перечисляем здесь только самые важные из них.

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

    Linux: интерфейсные стандарты и профили

    Проблема создания переносимых приложений возникла не вчера, но если во времена, когда большинство приложений разрабатывались на языке ассемблера, основным фактором, определяющим сложность переноса приложения между платформами, было сходство языков ассемблера соответствующих аппаратных архитектур, то сегодня на первый план выходит проблема стандартизации интерфейсов приложения с операционной системой.

    К настоящему времени разработано множество операционных систем, и можно с уверенностью сказать, что лидером по количеству разнообразных вариаций является Linux, однако обеспечение переносимости приложения во многих случаях требует дополнительных трудозатрат. И хотя разнообразие альтернативных операционных систем и различных вариаций одной и той же ОС предоставляет богатый выбор пользователям, это усложняет создание переносимых программ, способных работать на достаточно большом числе платформ.

    Один из способов упрощения переноса приложений между различными платформами – стандартизация в сфере интерфейсов взаимодействия операционной системы с приложениями. Следование стандартам API (Application Programming Interface) позволяет осуществлять перенос приложений на новые платформы путем их перекомпиляции, а целью стандартизации ABI (Application Binary Interface) является возможность переноса непосредственно бинарных файлов приложения без изменений. В качестве примеров соответствующих стандартов можно привести POSIX и LSB (Linux Standard Base) – первый позволяет осуществить сборку из исходного кода приложения, использующего только стандартизированные интерфейсы; второй гарантирует успешность запуска и корректность функционирования LSB-совместимого приложения в любой системе.

    Тем не менее зачастую оказывается, что при разработке определенного класса систем ориентироваться на один конкретный стандарт не получается – существующие спецификации либо слишком узки и не описывают всех необходимых интерфейсов, либо, наоборот, слишком объемны и содержат много информации, излишней для рассматриваемого класса задач. Так, базовая часть стандарта SUSv2 (Single UNIX Specification Version 2) была рассчитана на широкий класс систем и не описывала многих интерфейсов, необходимых для программ, функционирующих на рабочих станциях и ПК (в частности, GUI). И наоборот, анализ применимости стандарта LSB к системам, работающим на мобильных устройствах, показывает, что в данном случае многие возможности, описанные в LSB, оказываются неактуальными (например, подсистема печати и утилиты администрирования серверов). Однако вести разработку совершенно новых стандартов во многих случаях нецелесообразно, поскольку существующие спецификации уже охватывают большую часть предметной области. В таких ситуациях создаются профили стандартов, опирающиеся на существующие документы, но специфицирующие только те аспекты, которые важны для рассматриваемой предметной области.

    Подмножества стандарта востребованы, как правило, при создании узкоспециализированных продуктов – например, предназначенных только для работы на сервере, для обработки мультимедиа либо для установки в мобильных телефонах. Так, при разработке ОС реального времени полезен соответствующий профиль POSIX (IEEE Std 1003.13), а интерфейсы, описанные в других разделах этого стандарта (например, X/Open Curses – функции управления терминалом), в таких системах могут отсутствовать. Иногда необходимо объединить несколько стандартов с целью охвата сложной предметной области, включающей в себя множество разнородных компонентов, для каждого из которых приходится формулировать свои требования. Возможно объединение как стандартов целиком, так и их подмножеств. Например, профиль Carrier Grade Linux включает в себя только две части стандарта LSB – LSB Core и LSB CXX.

    Формально стандарт – это текстовый документ, регламентирующий набор требований к объектам стандартизации. Но одного текста, как правило, недостаточно для эффективного использования стандарта целевой аудиторией, особенно если стандарт достаточно велик. Стандарты, стремящиеся соответствовать веяниям времени, специфицируют множество интерфейсов – например, LSB версии 4.0 содержит описания более чем 38 тыс. функций из 57 библиотек. При таком количестве стандартизированных интерфейсов разработчикам приложений зачастую непросто проверить, что их программы используют только разрешенные функции. Для упрощения использования стандартов создаются различные дополнительные компоненты, формирующие окружение стандарта, – вспомогательные инструменты, информационные ресурсы и пр. Так, для многих стандартов (включая POSIX и LSB) доступны их онлайн-версии, сопровождаемые дополнительными материалами и комментариями. Например, LSB Navigator предоставляет информацию об интерфейсах, включенных в LSB, и описание причин отсутствия в стандарте ряда функций (наличие известных проблем с безопасностью, отсутствие обратной совместимости и др.).

    Помимо информационных ресурсов, в помощь разработчикам приложений могут предоставляться программные продукты, использование которых позволяет обойти определенные проблемы, возникающие в ходе создания удовлетворяющих стандарту продуктов. Так, для разработки программ, отвечающих требованиям LSB, может быть использован специализированный набор инструментов – LSB Software Development Kit (LSB SDK), применение которого автоматически решает ряд проблем, часто встающих перед разработчиками.

    Например, одной из причин несоответствия ряда приложений стандарту LSB является зависимость исполнимых файлов приложений от арифметических функций из libgcc_s, библиотеки поддержки компилятора GCC, которые не входят в LSB. В большинстве современных дистрибутивов Linux такие интерфейсы в libgcc_s присутствуют, и при сборке приложения в этих дистрибутивах могут появиться соответствующие зависимости, лишающие приложение совместимости с LSB. Для решения этой проблемы при сборке приложения можно использовать библиотеку libgcc_s из LSB SDK.

    На рисунке приведен перечень ресурсов, предоставляемых производителям дистрибутивов и приложений, ориентирующимся на стандарт LSB.

    Все компоненты, образующие окружение стандарта, должны быть согласованы между собой и с текстом стандарта – в частности, добавление и удаление интерфейсов из стандарта должно находить отражение во всех компонентах, где это необходимо. Для поддержания высоких темпов развития стандартов подобное обеспечение согласованности желательно автоматизировать – в противном случае разработка окружения может оказаться более трудоемкой, чем разработка самого стандарта.

    Интерфейсные стандарты открытых систем и их профили

    Появившись в конце 80-х годов, POSIX изначально описывал базовые системные функции, которые должны быть доступны приложениям. Эта часть стандарта не привязана к конкретной операционной системе или семейству ОС, и в настоящее время ее требованиям удовлетворяют как Unix-системы, так и некоторые редакции Windows (в частности, подсистема Unix встроена в редакции Windows Vista Enterprise и Ultimate). Разработчики glibc (GNU C Library) – основы всех дистрибутивов GNU/Linux – также ориентируются на совместимость с POSIX (хотя ни один из дистрибутивов Linux не проходил формальной сертификации на соответствие POSIX).

    Однако функций, входящих в POSIX, для большинства приложений недостаточно: «за бортом» остаются такие области, как графический интерфейс пользователя, мультимедиа и пр. Поэтому консорциум The Open Group в спецификации SUSv2, предшественницы POSIX 2001, служившей основой для сертификации UNIX 98, ввел три профиля:

    • UNIX 98 – соответствие базовой части стандарта;
    • UNIX 98 Workstation – базовый стандарт, дополненный требованиями к пользовательскому интерфейсу (в основе требований лежали графическая среда Common Desktop Environment и графическая библиотека Motif);
    • UNIX 98 Server – дополнительные расширения для поддержки различных сетевых сервисов, а также среды исполнения Java (на тот момент – JRE 1.1).

    В отличие от базовой спецификации, многие расширения в профилях Workstation и Server (в частности, CDE, Motif, X11 Window System) ориентированы на Unix-системы.

    Среди причин возникновения стандарта LSB было осознание того факта, что общепризнанные спецификации POSIX и Single Unix Specification слишком узки – попытка охватить большое количество систем (родственных, но все-таки достаточно далеких друг от друга) привела к тому, что многие широко используемые функции и команды либо вовсе не попали в спецификации, либо стандартизованной оказалась лишь небольшая часть их возможностей. С другой стороны, многие требования расширенных профилей Unix 98 не выполнялись в дистрибутивах Linux – например, отсутствовала свободная реализация среды CDE.

    Первоначальной целью Free Standards Group, занимавшейся созданием LSB, была разработка профиля-расширения базовой части POSIX, ориентированного только на дистрибутивы Linux. В результате появилась спецификация LSB Core, описывающая порядка трехсот функций, не входящих в POSIX, а также дополняющая описания многих функций из POSIX деталями, специфичными для Linux (например, расширяя наборы допустимых значений входных параметров и описывая поведение функции при таких параметрах или определяя дополнительные коды ошибок).

    Дальнейшим развитием LSB стало включение в спецификацию функций стандартной библиотеки C++, а также библиотек графического интерфейса пользователя, входящих в стеки Gtk+ и Qt. При этом для версий LSB 3.x дистрибутивам предоставлялась возможность сертификации на соответствие одному из трех профилей стандарта – Core, Core & C++ и Core & C++ & Desktop (последний профиль соответствует всему стандарту, а первые два являются его подмножествами). В LSB 4.0 такое разделение на профили было удалено, однако были добавлены опциональные требования, нарушение которых не препятствует получению сертификата.

    Разработчики LSB по-прежнему ориентируются на существующие спецификации – если некоторая функция уже описана в каком-либо документе, то в LSB публикуется не ее описание, а только ссылка на документ. В роли подобных документов могут выступать другие стандарты и документация, предоставляемая разработчиками библиотек (при условии, что она достаточно подробна и полна), например, для большинства функций Qt и Gtk стандарт LSB ссылается на соответствующие справочные руководства. Всего LSB 4.0 содержит ссылки более чем на 100 спецификаций.

    Еще одна особенность LSB происходит из того, что объектом стандартизации являются различные аспекты ABI, но поскольку многие аспекты ABI специфичны для конкретных аппаратных платформ, то для каждой платформы требуется своя версия стандарта (начиная с версии 3.2 LSB поддерживает семь аппаратных архитектур: x86, x86-64, IA64, PPC32, PPC64, S390 и S390X). Все семь версий имеют много общего – пересечение составляет порядка 90%, поэтому для облегчения работы со стандартом требования, общие для всех платформ, выделяются в отдельную спецификацию LSB Generic Specification.

    Параллельно с работами по развитию LSB, проводимыми Free Standards Group, шло создание других спецификаций и профилей, нацеленных на специализированные дистрибутивы Linux, используемые в определенных сегментах рынка. Так, организацией Open Source Development Labs (OSDL) был разработан профиль стандартов Carrier Grade Linux (CGL), определяющий требования, которым должен удовлетворять дистрибутив Linux, чтобы считаться системой класса carrier grade (в телекоммуникациях этим термином обозначают продукты, отличающиеся высокой надежностью и малым временем восстановления после сбоя). Последняя версия профиля, CGL 4.0, выпущенная в июне 2007 года, объединяет требования более чем тридцати стандартов и спецификаций, основными из которых являются LSB 3.0, POSIX 2001 и различные запросы комментариев (Request for Comments, RFC), в частности требования к реализациям протоколов IPv6, IPSec, SCTP и др. В начале 2007 года FSG и OSDL объединились, образовав консорциум The Linux Foundation, под эгидой которого теперь ведется разработка LSB и CGL.

    Попытки создания спецификаций предпринимались и в области встроенных и мобильных устройств, например, в 2002 году консорциум Embedded Linux Consortium разработал соответствующий профиль на основе LSB 1.2, POSIX 2001 и SUSv3. Из активно развивающихся открытых спецификаций для мобильных платформ стоит выделить LiMo Platform Specification, созданием которой занимается LiMo Foundation (помимо спецификации она разрабатывает и реализацию этой платформы), а также спецификацию для мобильной платформы Moblin, разрабатываемой Linux Foundation посредством расширения LSB. Из таблицы можно понять масштабы работ, проделанных в области стандартизации LSB.

    Инфраструктура LSB

    Сведения из базы используются для автоматической генерации частей различных компонентов окружения LSB (в частности, заголовочных файлов и библиотек-заглушек LSB SDK, а также некоторых тестовых наборов) и даже частей текста стандарта (например, перечней библиотек и предоставляемых ими функций). Автоматизация рутинных, но ресурсоемких задач позволяет осуществлять поддержку и развитие целого ряда продуктов (SDK, Navigator, наборы тестов libchk, cmdchk и др.) силами нескольких инженеров.

    Члены рабочей группы, занимающейся развитием стандарта, могут либо обращаться непосредственно к базе данных LSB, либо использовать аналитические инструменты, встроенные в Web-систему LSB Navigator. При этом все, что требуется сделать для включения определенного интерфейса в стандарт, – это пометить его соответствующим образом в базе данных. После этого происходит автоматический анализ зависимостей нового интерфейса, и сущности, необходимые для полноты спецификации (например, типы, используемые в качестве параметров новой функции), также добавляются в стандарт (естественно, члены рабочей группы получают отчеты о таких автоматически добавленных элементах).

    Навигатор полезен не только членам рабочей группы LSB, но и разработчикам, использующим LSB на практике, для них LSB Navigator предоставляет «интерактивную» версию стандарта, дополненную вспомогательной информацией и комментариями. В частности, для каждой функции, входящей в стандарт, можно увидеть ее сигнатуру, данные о ее присутствии в различных дистрибутивах и использовании в приложениях, а также получить ссылку на непосредственное описание поведения функции.

    Данные об интерфейсах, предоставляемых различными дистрибутивами, а также используемых приложениями Linux, необходимы для определения дальнейшего направления развития стандарта – на основе этих данных выделяются наиболее востребованные и распространенные библиотеки и функции, которые желательно стандартизировать в первую очередь, а также устаревающие и выходящие из употребления интерфейсы, вместо которых следует предлагать более совершенные аналоги. Наличие автоматизированных средств поддержки такого анализа позволило при создании LSB 4.0 обработать сведения обо всех версиях дистрибутивов 12 различных производителей, выпущенных за последние четыре года, и более чем о тысяче приложений.

    Инфраструктура позволяет автоматизировать формирование профилей на основе стандарта LSB, для чего в схеме базы данных введена специальная сущность, каждый экземпляр которой соответствует конкретному профилю. Индикатором того, что некоторый интерфейс включен в профиль, служит наличие связи между этим интерфейсом и соответствующим экземпляром сущности. Более того, если профиль формируется согласно некоторым формальным правилам, то эти правила можно заложить в инструменты, работающие с базой данных, с целью автоматического выделения профиля. Например, текущий инструментарий производит автоматическое отслеживание интерфейсов, включенных в спецификации для всех семи поддерживаемых архитектур, и добавляет их в спецификацию LSB Generic.

    Отметим, что база данных LSB используется не только для разработки самого стандарта и связанных с ним продуктов – информация о существующих дистрибутивах Linux востребована при анализе совместимости конкретных приложений с конкретными дистрибутивами. Возможность проведения подобного статического анализа (не требующего запуска приложений) предоставляется инструментом Linux Application Checker, разработку которого также ведет Linux Foundation совместно с ИСП РАН.

    Cервис для кампуса ННГУ

    Система LIST дает возможность студентам, сотрудникам и гостям кампуса Нижегородского государственного университета получать всю необходимую информацию о деятельности вуза. LIST позволяет ориентироваться на территории кампуса, узнавать расписание занятий и экзаменов, адаптирована к особенностям компактных мобильных устройств, содержит личные страницы студентов и сотрудников ННГУ, а также доски объявлений, форумы и чаты, тематические новостные каналы. Система разработана лабораторией физических основ и технологий беспроводной связи ННГУ в рамках академической программы компании Intel.

    Программирование с помощью картинок

    В исходном коде программ на графическом языке Sikuli, созданном в Массачусетском технологическом институте, могут встречаться не только обычные для языков программирования выражения и ключевые слова, но и изображения. Авторы нового языка считают, что некоторые задачи, например по автоматизации тестирования пользовательского интерфейса или поиску информации в базе данных, проще выполнять с помощью визуальных средств. Sikuli использует алгоритмы распознавания текста и индексации изображений с помощью «визуальных слов». Встроенные функции языка принимают в качестве параметров графические данные. Можно представить, например, команду для поиска на карте города нужного перекрестка: street_corner=find( ). Внутри скобок программист помещает фрагмент, который нужно отыскать на большой карте, выдаваемой сторонней программой. Предположим, что такая программа динамически отображает на карте положение городского автобуса, и тогда можно написать простую программу на языке Sikuli, которая будет следить, когда изображение автобуса появится на карте в границах найденного фрагмента.

    Читайте также: