Новый спецкурс «Архитектура дистрибутивов Linux»

В рамках совместного образовательного проекта факультета ВМК и Базальт СПО в этом семестре запущен новый спецкурс «Архитектура дистрибутивов Linux».

Спецкурс будет посвящён рассмотрению современного дистрибутива операционной системы GNU/Linux с точки зрения того, как архитектура операционной системы и особенности её эксплуатации определяют инструментальные характеристики дистрибутива, а также особенности сообщества, за ним стоящего. Во второй части спецкурса мы попробуем проанализировать с этой точки зрения другие «экосистемы» и сообщества вокруг них — комплекты дополнений к большим программным продуктам, хранилища библиотек и модулей для популярных языков программирования, дистрибутивы-«прошивки» (что успеем).

Архитектура дистрибутивов всего

Кто-нибудь может заметить, ничего себе «новый»! Начать с того, что товарищ лектор, ваш покорный слуга, последние десяток лет с лишним в принципе разговаривает именно о Linux-based дистрибутивах (и мы знаем эти дистрибутивы :) ). Но главное — курсов с таким или похожим названием за это время было сделано как минимум два, а если учитывать тематику, то штук пять, а то и шесть:

В чём новость-то?

А вот в чём. Спецкурсов по Linux (по крайней мере, с моим участием) на факультете не было уже два года, и не просто так, а по вполне определённой причине. Коротко говоря, ядро Linux и операционные системы на его основе слишком быстро и разносторонне развиваются. Долгое время казалось, что GNU/Linux-система — это такой осовремененный UNIX с полезными добавлениями, и что рассказывать о ней надо соответственно. Однако теперь мне очевидно, что т. н. «UNIX way» стремительно теряет статус универсального конструктора решений задач. То, что идёт ему на смену, в том числе в виде современной «начинки» Linux-based дистрибутивов, пока (?) недостаточно хорошо структурировано, слишком текуче, и совсем не годится в качестве отправной точки какого-либо академического подхода.

Вот три аргумента не то, чтобы «против» классического UNIX-way, но выявляющие его неуниверсальность:

  1. Принцип «сундука» UNIX: в операционную систему должно входить всё, что может понадобиться при решении рабочей задачи. Все инструменты должны иметь текстовый командный интерфейс, и решать атомарные подзадачи. Тогда пользователь сначала освоит работу с этими инструментами из командной строки, а затем применит оболочку (shell) для комбинации, суперпозиции и вообще высокоуровневой «обвязки», которая и будет решением задачи. Гениально же. А если чего-то не хватает, запрограммируйте это на Си (в сундуке, конечно, имеется).

    • Во многом необходимость иметь «утилиту на каждый чих» была продиктована отсутствием дисциплины совместной разработки, но ещё чаще — несвободным лицензированием этих утилит, и довольно низкой (дорогой, медленной) информационной связностью сообщества. Не стоит забывать, что сама разработка была уделом относительно немногочисленных программистов, кудесников в белых халатах, то есть процессом медленным и дорогим.
    • Сегодня подход «сундука», в первую очередь — стандартизованного по интерфейсам (POSIX, LSB) никуда не делся. Но высокая информационная связность и эффективность сообщества разработчиков таковы, что «запрограммировать решение на си плюс плюс» (на Perl, Python, node.js, Java, иное, … нужное подчеркнуть) зачастую выходит быстрее и эффективнее, чем комбинировать инструменты сундука в причудливые структуры.
    • Когда же информационная связность умножается на свободное лицензирование, выходит, что решение средних и больших задач всегда программно решается лучше, и быстрее, чем командно. Сундук UNIX содержит сотни утилит. Сундук интернета содержит сотни тысяч свободных библиотек для сотен языков программирования.

  2. Принцип «полного информационного пространства» UNIX: любая сущность в системе должна иметь документацию в информационной подсистеме. Ничего тайного и незадокументированого! Для всего есть man. Если man-а (то есть руководства) не хватает, есть примеры и справочники. Человек, конструирующий UNIX-решение, не нуждается в услугах телепата, кноуледж диггера и прочей эзотерике.
    • И снова этот принцип никуда не делся, однако здравый смысл подсказывает не пытаться задокументировать то, что изменится за время написания документации. Опять-таки вследствие существенно более эффективной, чем тридцать лет назад, организации разработки (и быстрее, и больше, и дисциплина опять же). То есть документация делится на три категории. На «долгоживущую» — это стандарты, неизменный интерфейс «сундука», базовые принципы. На «актуальную» — методички, советы, помощь: её нужно поддерживать, т. е. обновлять с обновлением любой из составляющих. И на «ненужную» — например, техдокументацию; «ненужная» она в том смысле, что специально делать её резону нет: она либо порождается сама грамотной дисциплиной разработки, либо ваша техническая документация оказывается написана на Си.

    • В какой-то момент произошёл качественный скачок: при решении рабочих задач с помощью Linux-конструктора подавляющую часть ответов на вопросы необходимо искать в Google, а не в информационной начинке дистрибутива. Это не отменяет подсистем man/info, просто они оказываются частью существенно большего и изменчивого информационного пространства.
  3. Наконец, и сама система, и её существование на компьютере в случае UNIX были достаточно статическими: пришёл системный администратор, установил, настроил, и запустил в эксплуатацию на долгие годы. Администратор будет регулярно навещать её, вдумчиво читать системные журналы, несколько раз в год что-то настраивать (например, добавлять или менять диск). В этом смысле крайне удачным ходом стало повальное представление всей информации в системе в виде читаемого текста. А если этот текст был ещё и структурированным (как например, сообщения в системном журнале), наступал праздник UNIXоида: написанныйим сценарий на awk или Perl по-умному автоматически читал этот текст и реагировал на него.
    • Проблемы подкрались с двух сторон. С одной стороны, масса задач в системе из статических превратились в динамические: подключение/отключение разнообразных внешних устройств (носителей и мультимедиа, например), настройка сети и авторизация в ней (WiFi, VPN), установки и — главное — обновление ПО, в том числе системного и т. п. С другой стороны, массовость использования Linux-окружений (облака, кластеры, blade-центры и пр.) совершенно изменила, как это и бывает при больших числах, представление о том, что ресурсоёмко, а что нет. Например, если некоторый демон стартует, когда вы перезагружаете компьютер раз в год, то ему позволено делать это несколько секунд или даже минуту. Но если он стартует всякий раз, когда подключается к сети, а вы путешествуете мимо беспроводных точек, ситуация меняется. Раз в год не многого стоит потратить на (пере-)настройку компьютера день-два. Но если таких компьютеров 1000, нужна целая бригада на весь год. А если вспомнить, что обновление системы происходит далеко не раз в год?

    • Потребность в динамическом решении задач привела к усложнению «интеллекта» системы, грань между «системным» и «прикладным» начала стираться: множество системных действий (например, распознание и подключение устройств) надо проводить автоматически, при этом используется «прикладной» интерфейс передачи типизированных данных (в Linux — DBus), вообще не предназначенный для чтения человеком. Стандартный подход UNIX «возьми из сундука, обмажь shell-ом» оказывается слишком тяжёлым, и заменяется на «перепиши на Си», особенно для мобильных и встраиваемых устройств, а в каких-нибудь системах изолированных окружений, типа Docker, намного проще, быстрее и безопаснее поднять несколько кое-как настроенных окружений с одним сервисом в каждой, вместо того, чтобы вдумчиво настраивать одно со всеми сервисами. О стандартизации взаимодействия между такими окружениями пока только задумываются.

О'кей, так о чём же таком рассказывать, что просуществовало бы хотя бы пять лет?

И вот здесь мне подумалось, что есть вполне определённая, приемлемо формализуемая цель, объединяющая и традиционные GNU/Linux-дистрибутивы, и дистрибутивы-«прошивки», и комплекты плагинов к толстым приложениям типа Firefox (чем не операционная система со своим кругом задач, политикой безопасности и прочим?), и «экосистемы» вокруг языков программирования, наподобие модулей Python, Perl или Ruby.

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

В любом случае приходится решать такие задачи

  1. Разработка компонентов
  2. Согласование их между собой
  3. Доставка до точки внедрения (в том числе и до сведения пользователя :) )

  4. Установка/настройка/обкатка
  5. Сопровождение эксплуатации

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

Условия существования дистрибутива вообще, навскидку:

  • Свободное распространение (а на самом деле — свободное лицензирование)
  • Совместная разработка
  • Грамотно организованное сообщество
  • Наличие удобных технологических инструментов для решения всех перечисленных задач

И вот тут выясняется, что старый добрый дистрибутив GNU/Linux решает эти задачи в целом чуть ли не лучше своих «младших братьев»!

Так примерно и вырисовался предстоящий спецкурс, на котором мы:

  • Рассмотрим вкратце, как устроена Linux-based ОС
  • Попробуем понять какими свойствами должен обладать дистрибутив такой ОС
  • Посмотрим на инструменты, обеспечивающие эти свойства
  • Посмотрим на организацию сообщества, за этим стоящего
  • Посмотрим, какие задачи решаются неэффективно

Затем

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

Вот так как-то.

Ах, да. Лекции записываются на видео, а видео выкладывается в YouTube, см. ссылки на страницах лекций.

Теперь всё.

FrBrGeorge


CategoryArticle


CategoryArticle

FrBrGeorge/News/2016-10-19 (последним исправлял пользователь FrBrGeorge 2016-11-02 14:26:00)