Операционные системы на основе ядра Linux: сообщество, дистрибутив, жизненный цикл

• Первая лекция в цикле «Школы фундаментальных технологий РБПО»

• трансляция в YouTube

План:

0. Представление

1. Что такое «Операционая система»?

   • Об истории термина «operating system»
     • ОС: разделение, унификация и учёт ресурсов компьютера
     • ОС: решение основных пользовательских (под?)задач

   • Архитектура «Цветочек»

     • Kernel space VS user space
     • Аппаратно: Танненбаум: 7, что ли, уровней… Современные архитектуры — 4: аппаратный, гипервизор, ядро, пользователь

     • +Микроядро: схема не обязана быть настолько монолитной в части kernel space

   • «Принцип сундука» (aka «Unix way»)

     • На каждую простую задачу должно быть решение + инструмент склейки

     • ⇒ упор на утилиты, классический Unix

   • «Принцип чемоданчика» (aka «Всё на свете можно запрограммировать на C++»)

     • Только самые необходимые инструменты, позволяющие создать решение любой задачи

     • ⇒ упор на инструменты разработки (они всё равно нужны всегда), Arduino

   • «Принцип гаража» (aka «Не пропадать же добру»)

     • Чем больше популярных задач будут иметь готовое решение, тем лучше

     • Упор на приложения, Windows

   • Комбинация принципов в современных ОС.
2. Что такое «Linux»?

   • Linux — это ядро ОС. Немного истории.

     • Minix, Линус и файловая система. Первое ядро.

     • Первый дистрибутив — Патрик, Slackware

     • Коммерциализация — Red Hat, SuSE, Mandrake …
   • А что такое «ядро ОС»?

     • Ядро — это API.

     • Те же функции, что и у ОС: унификация, разделение и учёт. В чём разница?

       • В kernel space разделение, унификация и учёт программные (их можно случайно или намеренно нарушить),

       • В user space ОС — структурные (сами ресурсы предоставляет ядро, а логика их обработки лежит в ОС).

   • Использование Linux (почти) без userspace
     • Встроенные и однозадачные системы
     • Android и иже с ним

3. Свободное лицензирование и открытая разработка

   • Картинка

     • См. Кордонский, Ланцберг «Технология группы» (Ядро - актив - аура - аудитория)

   • Принципы формирования свободного сообщества
     • Социальная значимость «общего дела»
     • Низкий порог входа-выхода
     • Произвольная мотивация
     • Динамическая профессиональная иерархия
     • Информационное пространство (документация/взаимодействие)
     • …
   • Открытая разработка как свободное сообщество
     • + Свободное распространение как условие развития
     • + Распределённая совместная разработка

   • Свободное лицензирование

     • Определение
       0. Право запускать программу

       1. Право изучать и изменять исходный текст для своих нужд

       2. Право распространять копии программы

       3. Право публиковать изменения в исходном тексте программы

     • Копилефт:

       4. Распространять разрешается на условиях, которые включают все пять пунктов исходной лицензии

   • Свободное лицензирование в бизнесе — это беспрепятственный обмен технологиями

   • Скорее всего, большинство подзадач уже имеют решение⇒ Google it first

4. Суперпозиция: что такое «Операционные системы на основе ядра Linux»?
   • Дистрибутив и репозиторий

     • Пакет как компонент ОС

     • Дистрибутив как продукт

     • Репозиторий как платформа для создания дистрибутивов

     • (замечание о терминологии: в Debian «дистрибутив» — это репозиторий, а «сборка» — это дистрибутив)

   • Роль сообщества в развитии дистрибутивов

     • Понятие сопровождающего (майнтейнера) пакета. Сообщество вокруг дистрибутива как сообщество сопровождающих.

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

     • Поддержка инфоресурсов (вики, телеграм, списки рассылки и т. п.)

   • Технические требования к репозиторию:
     • Пакеты подписаны сборочницей и собраются из исходников
     • Изоляция: процесс сборки не может повлиять ни на хост-систему, ни на другой процесс сборки
     • Цельность: минимизация «анметов» (неудовлетворённых зависимостей)

       • В Сизифе их давно уже нет

       • ⇒ Атомарные «задания» по (пере)сборке нескольких пакетов (например, при обновлении библиотеки)

     • Ведение истории (возможность собрать пакет на определённом «срезе» постоянно меняющегося репозитория)

       • ⇒ Стабильные ветки («платформы») для дистрибутивов

       • Воспроизводимая (с точностью до временных меток) сборка

     • Проверка и енфорсмент дисциплины разработки

   • ЖЦ дистрибутива
     • Один из вариантов на примере ALT Linux Team / Базальт СПО / Sisyphus
       0. Совместная разработка на базе репозитория

          • «Регулярные сборки»

       1. Подготовка «платформы» (стабильного среза) в рамках основного репозитория
          • Поиск и исправление ошибок в запланированных изменениях
          • Обновление версий популярного прикладного ПО (если ещё не)
          • Запрет на остальные глобальные изменения
          • Документирование
          • …

       2. Выпуск платформы: создание «стабильной ветки» репозиотрия

          • Более строгие правила попадания

          • «Стартовые сборки»

       3. Выпуск дистрибутива на базе платформы

          • Комплектация

          • Оформление

          • Документация

          • …
       4. Сопровождение дистрибутива

          • Техподдержка как услуга

          • Обновление платформы
            • новые версии популярного прикладного ПО
            • исправления ошибок и проблем с безопасностью
          • …

          • Поддержка сообщества

       5. Послеэксплуатационное сопровождение
          • Обновление до продукта следующей ветки: вспомогательные пакеты, например, библиотеки с несовместимым ABI, инструкции и т. п.
5. Подходы к информационной безопасности в «обычной» ОС
   • Что такое «безопасность»?
     • техническая VS административная составляющие

       • и то, и другое

       • есть мнение, что в первую очередь — административная!

     • секретность VS надёжность

       • и то, и другое

     • верифицируемость и доступность к экспертизе VS «security through obscurity»
       • а вот тут только первое: нафаззить можно любой интерфейс, хоть прозрачный, хоть запутанный, а чем проще и обширнее экспертиза, тем меньше шансов оставить уязвимость

       • Закон_Линуса (он же «принцип тысячи глаз»)

   • Техническая безопасность в системах общего назначения:

     • Дискреционые и мандатные права доступа

       • Суперпользователь и как с ним бороться

     • Изоляция (на уровне процессов, на уровне контрольных групп, на уровне виртуальных машин)

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

   • Безопасность как дисциплина:

     • криптостойкость: https://xkcd.com/936/

     • приватные ключи и токены
     • права суперпользовтеля
     • …
   • Безопасность в процессе разработки:

     • харденинг

     • дисциплина разработки
     • дисциплина оформления пакетов
   • Безопасность в процессе формирования репозитория и дистрибутива
     • Изолированная + воспроизводимая сборка
     • Отсутствие внешних воздействий в процессе сборки (например, отключение сети)
     • Подпись входных (srpm) и выкладываемых (rpm) пакетов
   • Виды дистрибутивов с точки зрения бизнеса и отношения к сообществу

     • Клоны: родительский дистрибутив оформляется как инструмент решения бизнес-задачи (которую он и так решает)

       • Не требует сообщества, не требует актива, зачастую не требует даже технических ресурсов
       • ⇒ Не имеет полноценного ЖЦ
       • Можно организовать и ликвидировать in no time

     • Деривативы: родительский дистрибутив дорабатывается для решения класса технологических и безнес-задач

       • «Разница» с родительским дистрибутивом сопровождается командой разработчиков (как правило, одной компанией), поддержка сообщества не требуется (она есть у родительского дистрибутива)
       • ⇒ ЖЦ строго строго завязан на родительский дистрибутив (релизы, изменения в непрофильном ПО и т. п.)
       • Можно сопровождать небольшой командой, полностью сосредоточенной на решении бизнес-задач

     • Аутентичные: нет родительского дистрибутива

       • Для сопровождения требуются усилия сообщества и профессионального актива, большая ресурсная база («сборочница»)
       • ⇒ ЖЦ целиком подконтролен сообществу или сообществу + продуктовой компании

       • Пригоден для изготовления из него клонов и деривативов!

6. История Linux в России на примере ALT Linux Team + Базальт СПО

   • 1999-2000 год — клон «Linux-Mandrake Russian Edition» (русификация)

   • 2001 год — формирование сообщества ALT Linux Team и выпуск деривативов «ALT Linux Junior 1.0» (создание собственной пакетной базы и выработка дисциплин) и «Castle» (внедрение наработок по безопасности, сертификация)

   • 2002 год — выпуск аутентичного дистрибутива «ALT Linux Master 2.0» (полностью своя пакетная база, контроль за процессом сборки); запуск линеек продуктовых дистрибутивов; формирование репозитория Sisyphus

   • 2004 год — компания ИВК выпускает дериватив на базе Sisyphus в составе комплексов «ИВК Кольчуга»

     • …строго говоря, вся программная разработка проделана компанией ALT Linux☺
     • …продукт развивается по сей день
   • 2008-2009 год — по заказу государства выпускаются семейство дистрибутивов «ПСПО» для образовательных учреждений
     • 2008 год: Пилотное внедрение проходит успешно при активной поддержке компании ALT Linux и сообщества

     • 2009 год: Попытка создать и поддерживать клон сторонними компаниями без участия компании-разработчика проваливается

   • 2009 год — успешный дериватив на базе Пятой платформы: «Simply Linux»

     • Впоследствии линейка Simply перешла под управление компании и сообщества
   • …
   • (просто чтобы не забыть) 2015 год — смена названия на «Базальт СПО»
   • …

   • На сегодня 2024-03-03 (2024-11-26):

     • Внедрения

     • Дистрибутивы: сертифицированный ФСТЭК, десктопные, серверный, сервер виртуализации, образоватеьный (сервер и десктоп)
     • Аппаратные платформы
       • tear 1: x86_64/i596, aarch64
       • tear 2: эльбрус, riscv64, loongrach64, mipsel, armh, ppc64le

     • Репозиторий: 19603 19987 пакетов; 415 325 активных майнтейнеров; 5751 7116 участников группы в Telegram; …

       • Резкое уменьшение числа майнтейнеров в этой статистике — это вымывание суперстарых пакетов, которые годами собирались без всякого сопровождения, а теперь перестали перестали; связано с Usrmerge, например

       • …что говорит об объективности самой статистики, конечно