Архитектура дистрибутивов всего
Кто-нибудь может заметить, ничего себе «новый»! Начать с того, что товарищ лектор, ваш покорный слуга, последние десяток лет с лишним в принципе разговаривает именно о Linux-based дистрибутивах (и мы знаем эти дистрибутивы 
). Но главное — курсов с таким или похожим названием за это время было сделано как минимум два, а если учитывать тематику, то штук пять, а то и шесть:
«Дистрибутивы Linux (2006)
«Дистрибутив Linux: архитектура, технология, сообщество» (2007)
«Программное обеспечение Linux» (2007)
«Сопровождение пакетов в Linux (2009)
«Программное обеспечение GNU/Linux» (2011)
В чём новость-то?
А вот в чём. Спецкурсов по Linux (по крайней мере, с моим участием) на факультете не было уже два года, и не просто так, а по вполне определённой причине. Коротко говоря, ядро Linux и операционные системы на его основе слишком быстро и разносторонне развиваются. Долгое время казалось, что GNU/Linux-система — это такой осовремененный UNIX с полезными добавлениями, и что рассказывать о ней надо соответственно. Однако теперь мне очевидно, что т. н. «UNIX way» стремительно теряет статус универсального конструктора решений задач. То, что идёт ему на смену, в том числе в виде современной «начинки» Linux-based дистрибутивов, пока (?) недостаточно хорошо структурировано, слишком текуче, и совсем не годится в качестве отправной точки какого-либо академического подхода.
Вот три аргумента не то, чтобы «против» классического UNIX-way, но выявляющие его неуниверсальность:
Принцип «сундука» UNIX: в операционную систему должно входить всё, что может понадобиться при решении рабочей задачи. Все инструменты должны иметь текстовый командный интерфейс, и решать атомарные подзадачи. Тогда пользователь сначала освоит работу с этими инструментами из командной строки, а затем применит оболочку (shell) для комбинации, суперпозиции и вообще высокоуровневой «обвязки», которая и будет решением задачи. Гениально же. А если чего-то не хватает, запрограммируйте это на Си (в сундуке, конечно, имеется).
- Во многом необходимость иметь «утилиту на каждый чих» была продиктована отсутствием дисциплины совместной разработки, но ещё чаще — несвободным лицензированием этих утилит, и довольно низкой (дорогой, медленной) информационной связностью сообщества. Не стоит забывать, что сама разработка была уделом относительно немногочисленных программистов, кудесников в белых халатах, то есть процессом медленным и дорогим.
- Сегодня подход «сундука», в первую очередь — стандартизованного по интерфейсам (POSIX, LSB) никуда не делся. Но высокая информационная связность и эффективность сообщества разработчиков таковы, что «запрограммировать решение на си плюс плюс» (на Perl, Python, node.js, Java, иное, … нужное подчеркнуть) зачастую выходит быстрее и эффективнее, чем комбинировать инструменты сундука в причудливые структуры.
Когда же информационная связность умножается на свободное лицензирование, выходит, что решение средних и больших задач всегда программно решается лучше, и быстрее, чем командно. Сундук UNIX содержит сотни утилит. Сундук интернета содержит сотни тысяч свободных библиотек для сотен языков программирования.
- Принцип «полного информационного пространства» UNIX: любая сущность в системе должна иметь документацию в информационной подсистеме. Ничего тайного и незадокументированого! Для всего есть man. Если man-а (то есть руководства) не хватает, есть примеры и справочники. Человек, конструирующий UNIX-решение, не нуждается в услугах телепата, кноуледж диггера и прочей эзотерике.
И снова этот принцип никуда не делся, однако здравый смысл подсказывает не пытаться задокументировать то, что изменится за время написания документации. Опять-таки вследствие существенно более эффективной, чем тридцать лет назад, организации разработки (и быстрее, и больше, и дисциплина опять же). То есть документация делится на три категории. На «долгоживущую» — это стандарты, неизменный интерфейс «сундука», базовые принципы. На «актуальную» — методички, советы, помощь: её нужно поддерживать, т. е. обновлять с обновлением любой из составляющих. И на «ненужную» — например, техдокументацию; «ненужная» она в том смысле, что специально делать её резону нет: она либо порождается сама грамотной дисциплиной разработки, либо ваша техническая документация оказывается написана на Си.
- В какой-то момент произошёл качественный скачок: при решении рабочих задач с помощью Linux-конструктора подавляющую часть ответов на вопросы необходимо искать в Google, а не в информационной начинке дистрибутива. Это не отменяет подсистем man/info, просто они оказываются частью существенно большего и изменчивого информационного пространства.
- Наконец, и сама система, и её существование на компьютере в случае UNIX были достаточно статическими: пришёл системный администратор, установил, настроил, и запустил в эксплуатацию на долгие годы. Администратор будет регулярно навещать её, вдумчиво читать системные журналы, несколько раз в год что-то настраивать (например, добавлять или менять диск). В этом смысле крайне удачным ходом стало повальное представление всей информации в системе в виде читаемого текста. А если этот текст был ещё и структурированным (как например, сообщения в системном журнале), наступал праздник UNIXоида: написанныйим сценарий на awk или Perl по-умному автоматически читал этот текст и реагировал на него.
Проблемы подкрались с двух сторон. С одной стороны, масса задач в системе из статических превратились в динамические: подключение/отключение разнообразных внешних устройств (носителей и мультимедиа, например), настройка сети и авторизация в ней (WiFi, VPN), установки и — главное — обновление ПО, в том числе системного и т. п. С другой стороны, массовость использования Linux-окружений (облака, кластеры, blade-центры и пр.) совершенно изменила, как это и бывает при больших числах, представление о том, что ресурсоёмко, а что нет. Например, если некоторый демон стартует, когда вы перезагружаете компьютер раз в год, то ему позволено делать это несколько секунд или даже минуту. Но если он стартует всякий раз, когда подключается к сети, а вы путешествуете мимо беспроводных точек, ситуация меняется. Раз в год не многого стоит потратить на (пере-)настройку компьютера день-два. Но если таких компьютеров 1000, нужна целая бригада на весь год. А если вспомнить, что обновление системы происходит далеко не раз в год?
Потребность в динамическом решении задач привела к усложнению «интеллекта» системы, грань между «системным» и «прикладным» начала стираться: множество системных действий (например, распознание и подключение устройств) надо проводить автоматически, при этом используется «прикладной» интерфейс передачи типизированных данных (в Linux — DBus), вообще не предназначенный для чтения человеком. Стандартный подход UNIX «возьми из сундука, обмажь shell-ом» оказывается слишком тяжёлым, и заменяется на «перепиши на Си», особенно для мобильных и встраиваемых устройств, а в каких-нибудь системах изолированных окружений, типа Docker, намного проще, быстрее и безопаснее поднять несколько кое-как настроенных окружений с одним сервисом в каждой, вместо того, чтобы вдумчиво настраивать одно со всеми сервисами. О стандартизации взаимодействия между такими окружениями пока только задумываются.
О'кей, так о чём же таком рассказывать, что просуществовало бы хотя бы пять лет?
И вот здесь мне подумалось, что есть вполне определённая, приемлемо формализуемая цель, объединяющая и традиционные GNU/Linux-дистрибутивы, и дистрибутивы-«прошивки», и комплекты плагинов к толстым приложениям типа Firefox (чем не операционная система со своим кругом задач, политикой безопасности и прочим?), и «экосистемы» вокруг языков программирования, наподобие модулей Python, Perl или Ruby.
Эта цель — создание дистрибутива, т. е. комплекта программного обеспечения для развёртывания и сопровождения программного продукта, решающего определённый широкий класс задач.
В любом случае приходится решать такие задачи
- Разработка компонентов
- Согласование их между собой
Доставка до точки внедрения (в том числе и до сведения пользователя
) - Установка/настройка/обкатка
- Сопровождение эксплуатации
Более того, по всей видимости, условия, при которых тот или иной дистрибутив как инфраструктурное явление вообще возможен, окажутся общими для всего вышепересисленного. а если где и появятся различия, так это ж самое интересное!
Условия существования дистрибутива вообще, навскидку:
- Свободное распространение (а на самом деле — свободное лицензирование)
- Совместная разработка
- Грамотно организованное сообщество
- Наличие удобных технологических инструментов для решения всех перечисленных задач
И вот тут выясняется, что старый добрый дистрибутив GNU/Linux решает эти задачи в целом чуть ли не лучше своих «младших братьев»!
Так примерно и вырисовался предстоящий спецкурс, на котором мы:
- Рассмотрим вкратце, как устроена Linux-based ОС
- Попробуем понять какими свойствами должен обладать дистрибутив такой ОС
- Посмотрим на инструменты, обеспечивающие эти свойства
- Посмотрим на организацию сообщества, за этим стоящего
- Посмотрим, какие задачи решаются неэффективно
Затем
- Попробуем приложить получившуюся «линейку» к другим комплектам ПО и сообществам
- Посмотрим, какие задачи и насколько эффективно в них решаются
- Если есть различия в целях и задачах (а они есть), попробуем вычленить, к каким различиям в инструментах и сообществе это приводит
Вот так как-то.
Ах, да. Лекции записываются на видео, а видео выкладывается в YouTube, см. ссылки на страницах лекций.
Теперь всё.