Цель минимизации Fedora

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

Некоторые современные типы развёртывания — такие как IoT и контейнеры — довольно чувствительны к размеру. Для IoT это обычно медленные каналы связи (для обновлений/управления), а для облачных сред и контейнеров — огромные масштабы.

Конкретный пример — Systemd. Хотя он очень полезен (все любят Systemd) и всегда присутствует на физических системах, в контейнерах он редко нужен. Поэтому не было проблемой, когда пакеты требовали Systemd только для systemd-sysusers для создания пользователей. Однако в контейнерах это означает значительное увеличение размера.

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

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

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

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

Итак:

В Fedora определяются конкретные сценарии использования. Затем сообщество сосредотачивается на этих сценариях с точки зрения разработки и сопровождения, оптимизации (например, минимизации) и тестирования (например, CI и gating). Эти сценарии использования могут прозрачно приоритизироваться для ресурсов инфраструктуры на основе интересов сообщества.

Feedback Pipeline активно отслеживает каждый сценарий использования и записывает размер и зависимости, необходимые для его работы. История данных сохраняется и отображается для отслеживания изменений с течением времени. А чтобы размер оставался небольшим, Feedback Pipeline также автоматически обнаруживает увеличение размера и потенциально автоматически открывает ошибки в Bugzilla для прозрачного отслеживания/исправления/обоснования таких увеличений.

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

Определить соответствующие сценарии использования и позволить сообществу (то есть не только команде минимизации) определять свои собственные. Мы рассматриваем сценарий использования как набор пакетов, установленных в определённом контексте и имеющих определённую цель, например, контейнер Apache HTTP Server. Определите сценарии использования как минимум для:

Кроме того, рассмотрите сценарии использования, характерные для контейнеров, например:

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

Расширить службы мониторинга (Feedback Pipeline), которые:

Помимо функций, нам также необходимо:

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

Минимизировать размер установки сценариев использования за счёт оптимизации зависимостей RPM, функций, программной архитектуры и других факторов. В частности, ищите:

Взаимодействовать с вышестоящими разработчиками в отношении более крупных изменений в упаковке и архитектуре. Примером является Systemd и разделение пакета systemd-sysuser.

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

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

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

В настоящее время не требуется никаких существующих ресурсов инфраструктуры Fedora или Release Engineering. Однако нам может потребоваться помощь в настройке (или получении доступа к) облачным ресурсам.

Активная поддержка со стороны наших сопровождающих, FPC и других членов сообщества определённо необходима. Это, очевидно, не то, что мы можем «запросить», но это всё равно необходимое условие.

Полезность важнее размера: Существует баланс между полезностью и размером. Мы учитываем это и не будем вносить кардинальные изменения, которые могли бы помешать нашим пользователям использовать Fedora. Однако ничто не мешает нам создавать дополнительные очень специфичные и минимальные артефакты.

Использование RPM: Мы делаем это с помощью RPM. Мы не достигаем минимизации путём удаления файлов после установки. Это может быть очевидно, но всё же стоит упомянуть.