Почему пакетная система Linux скорее всего доживает последние дни
Пакетная система Linux кажется чем-то классическим и незыблемым, тем, на чем держится вся система и отказ от нее видится многим каким-то кощунством. Но если разобраться трезво, то скорее всего мы увидим планомерный уход от этой схемы.
Первый звоночек прозвучал со стороны настольных дистрибутивов, где сначала начали массово применять универсальные приложения Flatpak и Snap, а в последнее время вовсю рассматривается концепция атомарного дистрибутива.
Атомарный дистрибутив не делится на пакеты и поставляется в виде готового образа, обновляется тоже весь целиком, монтируется только на чтение, чем обеспечивает пользователю, разработчику или администратору стабильную и предсказуемую среду.
Все знают: лучший способ сломать систему – наставить в нее левых пакетов. И такой зоопарк – настоящий ад для разработчика и администратора, потому что здесь работает, а здесь не работает. А все потому, что тут стоит библиотека А, а тут конфликтующая с ней библиотека Б, которая тем не менее предоставляет все функции библиотеки А.
Сторонние репозитории – это вообще туши свет, никому неизвестно что именно там содержится и насколько оно стабильно и безопасно. Да, есть проверенные авторы и репозитории, но никто не гарантирует, что они не сломают систему и что завтра кто-то вообще будет их сопровождать.
Вот тут мы подходим к самому важному и уязвимому месту системы – сопровождающим пакетов (maintainer) - это те люди, которые собирают и поддерживают пакеты для вашего дистрибутива.
В любом современном дистрибутиве пакетная база чаще всего делится на две части: поддерживаемая дистрибутивом и поддерживая сообществом. В первом случае вы еще можете с большой вероятностью рассчитывать, что пакет продолжит поддерживаться, во втором все зависит от сопровождающего.
Если он устал и забил – вы останетесь без пакета или его обновлений. И такое случалось не раз и не два, из того же Debain пропадал пакет phpMyAdmin, пропадал ряд других популярных утилит, а потом появлялся, так как нашелся новый сопровождающий или текущий вышел из спячки.
Отдельная проблема – это конфликты зависимостей. Дистрибутивы с длительной поддержкой работают по принципу заморозки мажорных версий пакетной базы. А разработчик приложения начинает использовать новую версию библиотеки, которой в дистрибутиве не было, нет и быть не может.
Для наиболее важных пакетов дистрибутивы используют бекпортирование – пересборку новых пакетов для текущего дистрибутива и размещение их в отдельном репозитории, но никто не гарантирует вам, что они не сломают именно вашу систему.
А для менее важных пакетов вы можете просто никогда не дождаться их в официальном репозитории на текущей версии системы.
И никаких здоровых альтернатив такая система не предусматривает: вы или качаете нужный пакет со стороны, либо собираете его сами, либо подключаете сторонний репо. В первых случаях вы берете на себя обязанности по сопровождению пакета в вашей системе, в последней – зависите от совершенно неизвестного вам источника.
В то же время современный сервер – это скорее всего гипервизор или движок контейнеризации и не предусматривает запуск полезной нагрузки непосредственно на сервере.
Из этого вытекает концепция «чистого хоста», на котором только движок виртуализации/контейнеризации плюс пара-тройка служебных утилит, остальное в изолированных средах.
При этом данные среды давно стандартизированы – OCI (Open Container Initiative) – это не только про Docker, это про универсальный формат контейнера, который вы можете запустить где угодно- хоть на докере, хоть на кубере, хоть в подмане или вообще на микроте.
И очень многие производители ПО переходят от бинарных пакетов именно к OCI (тот же SeaFile или Wiki.js), многие вообще не подразумевают других путей распространения.
А дальше просто напрашивается атомарная серверная система, которая у всех одинакова, стабильна и не предполагает вмешательства в базовый образ конечного пользователя.
