Зависимость ад: почему бы не создавать переносные приложения

Вернувшись вовремя, когда я использовал Windows, приложения были установлены независимым образом. Это оставило много свободы для конечного пользователя / sysadmin, чтобы решить, что и где обновлять, что исправлять и когда не мешать другим приложениям.

В * NIX запутанные зависимости – это болезненная головная боль. PC-BSD попытался преодолеть это с помощью PBI , создав автономные приложения. AFAIK, это кажется теперь устаревшим, и они вернулись к пути управления пакетами (PBI теперь является оболочкой для портов), и все дистрибутивы Linux работают в одном направлении: ожидается, что сотни зависимостей до самого конца, даже настольных окружений, будут зависеть на демонах управления системой .

Создание приложений на основе сотен зависимостей облегчает жизнь программистов, но создает потрясающую проблему для конечных пользователей и системных администраторов. Например, я не могу сохранить более старую версию приложения Debian для Etbian в Debian Jessie. Я знаю, что многие люди придут со сказкой о безопасности и исправлениях и новейших системах, но OpenSource означает свободу определять, что, когда и где обновлять. Есть очень веские причины не обновлять систему или ее часть или, по крайней мере, не делать этого так, как типичные менеджеры пакетов NIX ведут пользователей (т.е. машины, работающие в автономном режиме, старые аппаратные средства, совместимость со старыми данными, которые должны быть соблюдается, …). В других случаях системные администраторы предпочитают делать это в несколько шагов для обеспечения безопасности.

Лично я считаю, что я, как системный администратор, должен решить, что обновлять, а когда и нести риск. С нынешним положением дел это невозможно. (То есть, имея новую версию libc6 в Debian, это везде имеет зависимости). Если я решил оставить два или более хранилища для решения проблемы, я создаю еще один кошмар.

Я понимаю, что определенные зависимости (т. Е. С установленным MySQL) приемлемы, поскольку это основная зависимость, но я не могу понять, почему крошечные зависимости, такие как библиотеки, не просто встроены в код. Диск дешевый. Это обеспечило многие приложения Linux, перенесенные в Windows.

РЕДАКТИРОВАТЬ: обеспечить не только основанное на мнениях

Каковы варианты установки программного обеспечения в * NIX (давайте поместим его Debian / FreeBSD для простоты), чтобы:

  • Храните одну определенную версию программного обеспечения, работающую в течение многих лет без обновления, и убедитесь, что ее можно сохранить нетронутой, независимо от последующего обновления базовой ОС и библиотек, ala apt-get hold, но навсегда.

  • Решите, чтобы обновить / понизить, не противоречая другим программным средствам / библиотекам.

  • Установите две или более версии этого программного обеспечения.

Jails / chroot / VM не являются параметрами, хотя они являются очевидными обходными решениями. Также,

  • Что конкретно заставило PBI не достичь этой цели независимости, возвращаясь к управлению портами / пакетами?

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

Основным аргументом является безопасность, что, если в общедоступной библиотеке есть уязвимость, необходимо обновить только эту библиотеку, а не все приложения, которые используют эту библиотеку (благодаря совместимости с ABI). Это также означает, что (если вы придерживаетесь главным образом репозиториев и PPA (в случае Ubuntu)), вам не нужно иметь 4 разных версии библиотеки, установленных только потому, что ваши приложения были скомпилированы против этих версий (например, Windows , где у вас, вероятно, будут разные версии установленных библиотек .NET или установлены разные версии визуальной среды выполнения C ++).

Тем не менее, могут быть случаи, когда приложения не вынуждены использовать системную версию библиотек и могут вместо этого использовать свою собственную версию. Например, Chromium зависит от многих библиотек, которые присутствуют в репозиториях большинства дистрибутивов. В обычных условиях приложения будут скомпилированы таким образом, чтобы библиотеки, которые они использовали, были скомпилированы дистрибутивом. Однако в Ubuntu (по крайней мере) Chromium скомпилирован со своей версией библиотек, потому что:

  • Использование системной версии библиотек означает, что Chromium должен быть протестирован для каждой версии Ubuntu.
  • Хром, по большей части, использует последние версии библиотек уже, что означает, что вероятность наличия уязвимости намного ниже.

Что касается аргумента дискового пространства, вы можете утверждать, что для установки версии Debian для Debian для версии Debian Jessie требуется менее 1 ГБ дискового пространства, что отлично debootstrap для небольших SD-карт. Windows, с другой стороны, требует как минимум нескольких гигабайт дискового пространства.

Что касается более старого программного обеспечения, вы можете скомпилировать приложение статически и иметь большую часть зависимостей автономно. Однако, поскольку ваш дистрибутив может не иметь статических версий доступных библиотек (в большинстве случаев Debian и Ubuntu этого не делают), вам нужно будет скомпилировать эти библиотеки самостоятельно, чтобы получить статические версии этих библиотек.

Наконец, одним из принципов Unix является то, что каждое приложение делает только одно дело и хорошо работает. Если приложения и библиотеки были статически связаны, то их можно было бы (косвенно) считать многими.